Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!husc6!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: net.lang.c
Subject: fgets() returns NULL at EOF??
Message-ID: <1094@bu-cs.bu-cs.BU.EDU>
Date: Fri, 22-Aug-86 01:30:09 EDT
Article-I.D.: bu-cs.1094
Posted: Fri Aug 22 01:30:09 1986
Date-Received: Fri, 22-Aug-86 07:21:08 EDT
Organization: Boston U. Comp. Sci.
Lines: 28


fgets() returns a char * to the string read. Traditionally, any
function that cannot return a promised pointer (such as when an EOF
occurs) returns NULL (there exists a few syscalls which return ((char
*) -1) or equivalent, c'est la vie, this has been hashed out, I guess
the rule that syscalls return -1 won [eg. sbrk].)

puts() and fputs() always return the result of the last putc() done
(at least it does in 4.2/4.3bsd.) No mention of this is made in the
manual pages I have. This will be the last character of the string
unless an error occurred, in which case it will be EOF. Notice that
for puts() this will always be '\n' (or EOF on error.)

You're intuitions seem right, they should probably both return a
similar thing (ie. fputs() should probably return a pointer to the
string printed, or NULL on error, or maybe fgets() should return the
value of the last 'getc()' done, I like the former better.) Oh well,
such is history.

Of course, in the case of getc() et al, EOF makes sense as an
out-of-band character (ie. a value that cannot be a legal char,
hence distinguishable, but no relation to a pointer.)

Thus, fgets() is consistent with the idea of returning a NULL as
a failed pointer while fputs() is consistent with the documentation
in that the doc seems to promise nothing...

	-Barry Shein, Boston University