This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use __unused0 instead of __unused for user visible struct members
- From: Justin Cormack <justin at specialbusservice dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 30 Oct 2013 08:37:27 +0000
- Subject: Re: [PATCH] Use __unused0 instead of __unused for user visible struct members
- Authentication-results: sourceware.org; auth=none
- References: <CAK4o1WzkMk8nV2jzM38peutbMWuKBPTeh5dbfwSiDhankAT=Yw at mail dot gmail dot com> <20131030014426 dot GB20515 at brightrain dot aerifal dot cx>
On Wed, Oct 30, 2013 at 1:44 AM, Rich Felker <firstname.lastname@example.org> wrote:
> On Mon, Oct 28, 2013 at 12:18:35PM +0000, Justin Cormack wrote:
>> A patch was submitted for this a while back
>> https://sourceware.org/ml/libc-alpha/2012-01/msg00001.html and did not
>> get a good reception from the maintainer at the time. Attached is an
>> updated version for current glibc head.
>> The issue here is that use of __unused as a struct member name
>> conflicts with the historic use of __unused on BSD systems and code
>> for __attribute__((__unused__)) - unfortunately this has become part
>> of the user visible API of these systems. In my case I am trying to
>> cross compile NetBSD on ppc Linux and there is no way to do this
>> without patching the headers. In general most uses of __unused are
>> already __unused1, __unused2 etc, it is just a few cases that are not.
>> These fields are not part of the user API so these changes should not
>> affect any code outside glibc itself.
> While it doesn't mean I disagree with this change (because such apps
> are broken nonsense and need to be fixed) I wouldn't be surprised if
> it breaks at least a few apps which are accessing __unused members by
> name (e.g. to zero-fill padding).
I think these have changed before as the user facing structs have
changed their padding. And one hopes people have compiled on more than
one architecture, although probably not. From the other side, the
NetBSD tools team seem to be interested on removing their use of