> yeah. the number of bytes returned seems like a mistake in the api design.
sorry, but that comes off like a clever soundbite. the return value informs about the expansion size after the format strings processing, and i am sure someone has used that information in a place where it was useful. especially in the world before snprintf arrived [Torek, I'd guess around 1998?], after that you could snprintf / asprintf, and then fwrite, and know the size. I'd like to point out this API is probably older than you, and I've never read this type of criticism before. > there is almost nothing one can do with this information. I'm sure someone in the past has been happy to know the expansion size. i'm sure there are purposes for knowing it. 'retrying write' isn't the only possible reason. furthermore, 2 of the 3 errno *printf were only intruduced in the last 15 years, and I doubt ENOMEM was well documented before that time. > i mean, what? only in the case of snprintf can the return be used, and the > idea of "short" write there is only harmful. suspect you described that wrong. the return value from snprintf and asprintf have been used throughout the tree, and if anything the addition of -1 / EILSEQ by solaris has made things tricker. > returning -1 to indicate error, ignoring the possibility of short > output, seems like the option that results in less damage. as an > application author, it's the only behavior i can reasonably code > against. I don't believe that. It may be possible to come to a conclusion like that, if review of a large body of code found at least a few checks for -1 / ENOMEM, or just -1 on it's own. If no old instances are found, is that a case of people not being reasonable application authors? No, I think it is just a gap -- really nothing new.
