This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Jun 14, 2017 at 7:08 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/10/2017 07:17 PM, Zack Weinberg wrote:
>> +printf '#include <features.h>\n#include <bits/errno.h>\n' |
>> +    $CC -E -dM -xc -D_GNU_SOURCE -D_ERRNO_H "$@" - > "$tmp1"
>
> I'm worried this fails to produce a header which is multi-arch-clean
> (i.e., on x86-64, produce something which is compatible with x86-64,
> i386, and x32).  Maybe the situation is better than with the system call
> list; at least a cursory glimpse at the kernel sources suggests that
> these headers don't have multi-arch preprocessor conditionals there.

Hmm, yes.  Right now, at least on x86-64, the set of errno constant
*names* is consistent across all three subarchitectures, but there's
no guarantee of that.

> 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.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]