On Tue, Dec 31, 2002 at 11:07:31AM -0500, Ronald Henderson wrote:
> The attached patch cleans up processing return values for most of the
> snprintf and vsnprintf functions in "proto.c".
Checked in.
> Different C runtime libraries
> may produce different results for these functions when the size limit is
> exceeded. The char buffer may not be null terminated ('\0') as a result.
I assume one of the different results is the lack of null termination;
the FreeBSD 3.4 man page says
Snprintf() and vsnprintf() will write at most size-1 of the characters
printed into the output string (the size'th character then gets the ter-
minating `\0');
indicating that the last '\0' is put in even if the string is truncated.
The Red Hat 7.3 man page at
http://www.FreeBSD.org/cgi/man.cgi?query=printf&apropos=0&sektion=3&manpath=Red+Hat+Linux%2Fi386+7.3&format=html
doesn't seem to clearly state whether the '\0' is put in or not. The
Solaris 8 man page at
http://www.FreeBSD.org/cgi/man.cgi?query=snprintf&apropos=0&sektion=0&manpath=SunOS+5.8&format=html
does, however, say it's put in:
The snprintf() function is identical to sprintf() with the
addition of the argument n, which specifies the size of
the buffer referred to by s. The buffer is always termi-
nated with the null byte.
It's harmless (other than wasting a few cycles, which probably won't be
noticed) to put the '\0' in there if it's already there, though, so we
might as well do it unless we're *absolutely certain* that *all*
versions of "snprintf()"/"vsnprintf()" that would *ever* be used with
Ethereal put it in.
