| |||||||||||
snprintf() confusionsnprintf() confusionPosted Feb 6, 2004 23:50 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: snprintf() confusion by ThePythonicCow Parent article: snprintf() confusion 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 I 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.
(Log in to post comments)
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.
|
|||||||||||