This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 5/6] Make error_t an enumeration on all supported OSes.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Zack Weinberg <zackw at panix dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 14 Jun 2017 15:57:30 +0200
- Subject: Re: [PATCH 5/6] Make error_t an enumeration on all supported OSes.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B0074804F2
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B0074804F2
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com>
Joseph Myers <firstname.lastname@example.org> writes:
> On Wed, 14 Jun 2017, Florian Weimer wrote:
>> Zack Weinberg <email@example.com> writes:
>> > We could conceivably change __errno_location to return an error_t,
>> > which would mean 'p errno' in GDB would print symbolic values without
>> > needing to cast it, but I hesitate to make the apparent type of errno
>> > not be 'int'.
>> That sounds a bit hackish because I'm not sure int * and error_t * are
>> types with that level of compatibility.
> Type compatibility is not transitive, and errno is required to have type
> int. Thus, if enum foo is an enum whose type is compatible with int
> (following the implementation-defined rules for what integer type an enum
> is compatible with), then _Generic (errno, enum foo: 0) is a valid C11
> expression, which would not be valid if errno had an enum type other than
> enum foo (two enum types compatible with the same integer type are not
> compatible with each other).
Perhaps a GDB plugin would be a better way to add this functionality?