src/lib/libc/stdio/vsnprintf.c, branch stable/4

MFC revision 1.22: When size is 1 should just null terminate the string.

2003-08-27T18:20:57Z

This fix has the side effect of making vsnprintf() properly return the length of the string that would have been created if the buffer were infinite length when the passed size is 1. Previously, it would erroniously return 0 which causes auto-extending sbufs to misbehave in userland apps linked against libsbuf. Approved by: re (jhb)

MFC rev. 1.21: fix vsnprintf(3) memory leak for size == 0.

2002-09-23T06:58:17Z

Approved by: re (jhb)

$Id$ -> $FreeBSD$

1999-08-28T00:22:10Z

1. EOF was returned when the buffer size was larger than INT_MAX. This

1998-01-01T20:15:58Z

case has very little to do with the output size being larger than INT_MAX. 2. The new #include of was disordered. 3. The new declaration of `on' was disordered (integer types go together). 4. Testing an unsigned value for > 0 was fishy. Submitted by: bde

Correct type of stored argument place (from previous fix)

1997-12-24T23:54:19Z

Return back to BSD snprintf semantics which recent C9x standard adopts

1997-12-24T23:02:47Z

instead of Singe Unix, thanx Bruce for explaining, I am not realize standards war was there. But now, fix n == 0 case to not return error and fix check for too big n. Things left to do: check for overflow in arguments.

1) Oops! Insert again if (n == 0) return 0.

1997-12-24T20:24:08Z

Final word is Bruce's quote: C9x specifies the BSD4.4-Lite behaviour: [#3] ... Thus, the null-terminated output has been completely written if and only if the returned value is less than n. It means that if we not have any null-terminated output as for n == 0 we can't return value less than n, so we forced to return value equal to n i.e. 0 The next good thing is glibc compatibility, of course. 2) Do check for too big n in machine-independent way. 3) Minor optimization assuming EOF is < 0

Back out part related to "return 0 if n == 0" and return EOF as before.

1997-12-24T14:32:40Z

The main argument is that it is impossible to determine if %n evaluated or not when snprintf return 0, because it can happens for both n == 0 and n == 1. Although EOF here is good indication of the end of process, if n is decreased in the loop... Since it is already supposed in many places that EOF *is* negative, f.e. from Single Unix specs for snprintf "return ... a negative value if an output error was encountered" this not makes situation worse.

snprintf return value fixes to conform Single Unix specs:

1997-12-24T12:31:32Z

1) if buffer size is smaller than arguments size, return buffer size, not arguments size as before. 2) if buffer size is 0, return 0, not EOF as before. (now it is compatible with Linux and Apache implementations too). NOTE: Single Unix specs says: If the value of n {buffer size} is zero on a call to snprintf(), an unspecified value less than 1 is returned. It means we can't return EOF since EOF can take *any* value in general not especially < 1. Better variant will be return -1 (it is less then 1 and different with n == 1 case) but -1 value is already occuped by EOF in our implementation, so we can't distinguish true IO error in that case. So 0 here is only possible case still conforming to Single Unix specs.

Revert $FreeBSD$ to $Id$

1997-02-22T15:12:41Z