[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140827171400.GR12888@brightrain.aerifal.cx>
Date: Wed, 27 Aug 2014 13:14:00 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: fgets behaviour after eof
On Wed, Aug 27, 2014 at 01:16:20PM +0200, Szabolcs Nagy wrote:
> However the behaviour of fgets(s, 1, f) is unclear if feof(f) is true,
> in this case nothing is read so fgets cannot "encounter" end-of-file,
> so it may set s[0]=0 and return s or it could check feof and return 0.
> (glibc does not check feof)
Sorry, I missed the fact n==1. In this case, no read ever occurs (0
bytes have already been read) so the following text simply applies:
"The fgets() function shall read bytes from stream into the array
pointed to by s, until n-1 bytes are read, or a <newline> is read and
transferred to s, or an end-of-file condition is encountered. The
string is then terminated with a null byte."
and of course:
"Upon successful completion, fgets() shall return s."
This is all handled correctly in the special case at the top of the
function. The only thing that may be incorrect is the failure to wait
on the file lock in this case; formally, all operations on FILE are
supposed to obtain the lock, and presumably fgets(f, 1, &(char){0})
could be a sort of 'barrier' to "wait until thread with lock on f has
unlocked it".
Your other correction at the end of the function, when EOF or error
was seen, still applies though.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
