8 Commits

Author SHA1 Message Date
ache
7bbce1048f 1) Oops! Insert again if (n == 0) return 0.
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
1997-12-24 20:24:08 +00:00
ache
1756dc5a15 Back out part related to "return 0 if n == 0" and return EOF as before.
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.
1997-12-24 14:32:40 +00:00
ache
46f0000bfe snprintf return value fixes to conform Single Unix specs:
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.
1997-12-24 12:31:32 +00:00
peter
6b08958c64 Revert $FreeBSD$ to $Id$ 1997-02-22 15:12:41 +00:00
jkh
808a36ef65 Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
1997-01-14 07:20:47 +00:00
jraynard
fac2ce3b12 Suggested by: Bruce Evans, Jeffrey Hsu, Gary Palmer
Added $Id$'s to files that were lacking them (gpalmer), made some
cosmetic changes to conform to style guidelines (bde) and checked
against NetBSD and Lite2 to remove unnecessary divergences (hsu, bde)

One last code cleanup:-

Removed spurious casts in fseek.c and stdio.c.
Added missing function argument in fwalk.c.
Added missing header include in flags.c and rget.c.
Put in casts where int's were being passed as size_t's.
Put in missing prototypes for static functions.
Changed second args of __sflags() inflags.c and writehook() in vasprintf.c
from char * to const char * to conform to prototypes.

This directory now compiles with no warnings with -Wall under
gcc-2.6.3 and with considerably less warnings than before with the
ultra-pedantic script I used for testing. (Most of the remaining ones
are due to const poisoning).
1996-06-22 10:34:15 +00:00
julian
619b731f5b Reviewed by: julian and (hsu?)
Submitted by:	 John Birrel(L?)

changes for threadsafe operations
1996-01-22 00:02:33 +00:00
rgrimes
be22b15ae2 BSD 4.4 Lite Lib Sources 1994-05-27 05:00:24 +00:00