On Mon, Sep 28, 2015, at 10:30 AM, ellie timoney wrote:
> > AFAIK snprintf() doesn't write the final \0 in the case the string would
> > overflow the buffer, so with size 6 you might end with "foobar" instead
> > of "fooba\0". I think this was the problem the patch was trying to
> > remedy. But perhaps it's not an issue anyway.
>
> I sat down and tested this, and you're correct: it won't zero-terminate
> if it runs out of space to do so, so we need to do so ourselves.
>
> I've fixed this now (ff4e6c7), and also fixed the function immediately
> above it that had the same problems :P
Would you believe I just had another look at my own test code... and it
had a bug in it (doh!)
So snprintf() is actually working the way I first thought it worked, and
the way the documentation implies that it works: (using your example) it
correctly produces "fooba\0" for "foobar", length 6.
So there's no documentation bug here, and the fix was unnecessary -- at
least on Debian. I'll leave it in place though, in case some other
platform (or older libc, etc) exhibits the behaviour you originally
expected.
> The man page for snprintf on Debian is a bit vague/misleading about
> this. Reading it, I was under the impression that it would always
> zero-terminate, even if that would lead to truncation. It talks a bit
> about detecting truncation, but doesn't mention that it doesn't always
> zero-terminate (and, to my eyes, sort of implies that it actually does):
>
> > DESCRIPTION:
> > The functions snprintf() and vsnprintf() write at most size bytes
> > (including the terminating null
> > byte ('\0')) to str.
> >
> > Return value:
> > The functions snprintf() and vsnprintf() do not write more than
> > size bytes (including the terminat‐
> > ing null byte ('\0')). If the output was truncated due to this
> > limit, then the return value is the
> > number of characters (excluding the terminating null byte)
> > which would have been written to the
> > final string if enough space had been available. Thus, a return
> > value of size or more means that
> > the output was truncated. (See also below under NOTES.)
> >
> > NOTES:
> > (talks about overlapping src/dest buffers and return values)
> >
> > BUGS:
> > (talks about snprintf and vsnprintf as solutions to overflow
> > problems, but doesn't mention they have their own)
>
> The man page for strncpy, which exhibits the same behaviour, talks at
> length about the need to ensure zero termination yourself. Not sure if
> this is an snprintf bug or a documentation bug (or both) ...
