Re: [PATCH 3/7] read_in_full: reset errno before reading

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 25, 2017, 23:52 UTC
Message-ID: <20170925235230.GK27425@aiede.mtv.corp.google.com>
In-Reply-To: <20170925233732.4lqavl56qwpfjuxy@sigill.intra.peff.net>

Jeff King wrote:

> On Mon, Sep 25, 2017 at 04:33:16PM -0700, Jonathan Nieder wrote:
>> Jef King wrote:

>>>   errno = 0;
>>>   read_in_full(fd, buf, sizeof(buf));
>>>   if (errno)
>>> 	die_errno("oops");

[...]

Show 15 quoted lines

>>>                          in general we frown on it for calls like
>>> read().
>>
>> 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.

Yes, it is allowed to set it to another random value. It's a common thing for implementations to do when they hit a recoverable error, which they sometimes do (e.g. think EFAULT, EINTR, ETIMEDOUT, or an implementation calling strtoul and getting EINVAL or ERANGE).

glibc only recently started trying to avoid this kind of behavior, because even though the standard allows it, users hate it.

POSIX.1-2008 XSI 2.3 "Error Numbers" says

	Some functions provide the error number in a variable accessed
	through the symbol errno, defined by including the <errno.h>
	header.  The value of errno should only be examined when it is
	indicated to be valid by a function's return value.

See http://austingroupbugs.net/view.php?id=374 for an example where someone wanted to add a new guarantee of that kind to a function.

Hope that helps, Jonathan