On Mon, Sep 25, 2017 at 07:37:32PM -0400, Jeff King wrote:
> > Correct. Actually more than "frown on": except for with the few calls
> > like strtoul that are advertised to work this way, POSIX does not make
> > the guarantee the above code would rely on, at all.
> >
> > So it's not just frowned upon: it's so unportable that the standard
> > calls it out as something that won't work.
>
> Is it unportable? Certainly read() is free reset errno to zero on
> success. But is it allowed to set it to another random value?
>
> I think we're getting pretty academic here, but I'm curious if you have
> a good reference.
Answering my own question. POSIX says:
No function in this volume of IEEE Std 1003.1-2001 shall set errno to
0. The setting of errno after a successful call to a function is
unspecified unless the description of that function specifies that
errno shall not be modified.
So that does seem to outlaw errno-only checks for most functions.
It makes me wonder if the recent getdelim() fix is technically violating
this. It should instead be explicitly checking for feof().
> IMHO as long as it _is_ deterministic and recognize as not an error from
> read(), that's the best we can do. Which is why I went with "0" in the
> first place. Seeing "read error: success" is a common-ish idiom (to me
> anyway) for "read didn't fail, but some user-space logic did", if only
> because it often happens accidentally.
Another option I ran across from POSIX:
[EOVERFLOW]
The file is a regular file, nbyte is greater than 0, the starting
position is before the end-of-file, and the starting position is
greater than or equal to the offset maximum established in the open
file description associated with fildes.
That's not _exactly_ what's going on here, but it's pretty close. And is
what you would get if you implemented read_exactly() in terms of
something like pread().
-Peff
