Re: [PATCH 5/6] Make error_t an enumeration on all supported OSes.

[Florian Weimer <fweimer at redhat dot com>]

Zack Weinberg <zackw@panix.com> writes:

> On Wed, Jun 14, 2017 at 7:23 AM, Zack Weinberg <zackw@panix.com> wrote:
>> On Wed, Jun 14, 2017 at 7:08 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> It would be safer to have a built-in list of possible errno constant
>>> names and generate a header from that, similar to what I did for the
>>> system call names (but for which we failed to reach consensus).
>>
>> Come to think of it, we already have such a list - errnos.texi - and
>> it already has to be exhaustive, otherwise strerror() won't work for
>> all error numbers.  OK, I'll make that change.
>
> This turns out not to work for the Hurd, which has a number of errors
> that are copied from Mach kernel headers and not defined in
> errnos.texi (see sysdeps/mach/hurd/bits/errno.h - the constants
> beginning with EMACH_, EKERN_, EMIG_, and ED_).  These are already
> problematic, strerror() doesn't work for them and some of them violate
> the ISO C requirement for all error constants to be positive numbers,
> but since error_t was invented for the Hurd in the first place, I'm
> reluctant to drop their error codes out of their enum...  I suppose I
> could invent some sort of hook for extending the list of errno
> constant names in sysdeps, but does anyone have a better idea?

Realistically, your only chance is not to change the Hurd code at all
because we currently do not have a way to test it, do we?

So for Linux, you could come up with a separate mechanism and generate
error_t there.  But I have no concrete advice in that direction, sorry.

Thanks,
Florian