| |||||||||||
snprintf() confusionsnprintf() confusionPosted Feb 5, 2004 8:43 UTC (Thu) by ThePythonicCow (subscriber, #11308)In reply to: snprintf() confusion by IkeTo Parent article: snprintf() confusion Historically, there have been two variants of snprintf, with the ISO C99 standard, taken from BSD, of returning the length of the entire formatted string, even if it didn't entirely fit. Earlier versions of snprintf only returned a count of how many non-nul characters went into the buffer. This earlier return convention was actually "obvious" at the time -- no one on those slow, old machines would expect a C library routine to be wasting its CPU cycles calculating the length of some formatted output that it wasn't going to output. And my impression is that most of us old timers are surprised by the new convention. This new convention is also not worth much in most kernel code, which doesn't do anything with the extra information anyway. If the intended output doesn't fit (it's usually a console print or something) then tough - it gets truncated. Not usually worth the bother to try to expand the buffer size (and you have to be careful, not to open the kernel up to a Denial of Service attack, if the user can somehow persuade it to attempt to print something that's surprisingly long. Still, Linus has clearly chosen the new ISO C99 standard (someone backed the lib/vsprintf.c code off to the "old standard", and Linus restored the C99 conventions.
(Log in to post comments)
snprintf() confusion Posted Feb 6, 2004 23:50 UTC (Fri) by giraffedata (subscriber, #1954) [Link] This earlier return convention was actually "obvious" at the time -- no one on those slow, old machines would expect a C library routine to be wasting its CPU cycles calculating the length of some formatted output that it wasn't going to outputI doubt the wasted computation entered into the decision. The reason the old behavior was obvious at the time is that the function is emulating printf(), which like all Unix I/O routines, returns the number of characters transferred. The modern sprintf return value, though useful, is actually quite unconventional.
snprintf() confusion Posted Feb 7, 2004 10:00 UTC (Sat) by ThePythonicCow (subscriber, #11308) [Link]
Your last words:
snprintf() confusion Posted Feb 7, 2004 18:09 UTC (Sat) by giraffedata (subscriber, #1954) [Link] it's not like printf has a choice of two possible lengths to choose from. It writes whatever it has format for, and counts it all (or SEGV's trying). OK, I see in the printf case, a partial write isn't practical. But it doesn't really weaken the argument that printf is an I/O routine, and so it is natural to follow the pattern of write() and fwrite() and return the number of bytes written. The leap from there to snprintf() is a lot more obvious when you include the sprintf() step. sprintf(), derived from printf(), quite naturally returns the number of characters formatted, just like printf(). And it's a very useful value, too. snprintf() was derived from sprintf(), and merely adds a constraint on the length; If you're going to drop it in to replace a dangerous sprintf(), you clearly want it to do the same as sprintf() and return the number of characters formatted.
snprintf() confusion Posted Feb 7, 2004 18:56 UTC (Sat) by ThePythonicCow (subscriber, #11308) [Link] Yeah - that makes sense.
|
|||||||||||