Debian patches that really belong to upstream

[ellie timoney]

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) ...