From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14492 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: James Y Knight Newsgroups: gmane.linux.lib.musl.general Subject: Re: Support SIGEV_THREAD_ID Date: Thu, 1 Aug 2019 14:00:44 -0400 Message-ID: References: <20190801164958.GH9017@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e9d135058f12060e" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252676"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14508-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 01 20:01:30 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1htFOK-0013aj-8D for gllmg-musl@m.gmane.org; Thu, 01 Aug 2019 20:01:28 +0200 Original-Received: (qmail 19732 invoked by uid 550); 1 Aug 2019 18:01:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19712 invoked from network); 1 Aug 2019 18:01:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ze8W+1Sa76vD8ZGTEcHstAlWtEkTPt0oW1yMZjHN9hM=; b=Ji+68f+93T8bB/vyGuXd59hTVyhqJbLG3tWIyhvOi3I/Wd6NiWmHr3OYK6voVE6pNi dBYE/YJkNzaDsMxPbMBwYhLXYXx6W2BndKnD3AGy/fMVOZhBJAm3r4ojWJ14R9SNtSEY zsZI0cdLIKuGRNvP1AY/+Oa4EZa3TIurDx7UkBcFN6U1r7yhAZbHeYEjVKYG6ra6+JQX SG8RLsLpcoi9bjRK1zJSRqnBfs6ytT5DPl1MlY2Qlybv2PxNW4DeatUdKoH0qfbFOUFT oP1hG1XY0ikKSH+MsV9EvGOJ9eppur3+4wZJ5bYowKhRuhlZNrgB/2LQNvzcfKFHVFXM B/LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Ze8W+1Sa76vD8ZGTEcHstAlWtEkTPt0oW1yMZjHN9hM=; b=seLtCfoyQXeBLe30Onvkh2XAztWK4nVmiOOcMF3/9wFD08JtLXvjd0bX51d1TAn0Eo twjIhbM6kjCx+37iPB/RwRZj8pUHU8eh0AqVFKRffZlEZNaalWVNVuK3+hRBKmXArb1M a3l1ibxqL0rE5eJNlnVQamZVA5rNIUBaMYLzWi0hqphqnwd0BpNreQ0hf/HgPNkpz8bP tJKr1spWAvxkz1TE2kmse0caDW3DPlfSbzzCumt2w8xjv1a/f9Bjq/hX4bPE3J2VYtpW awBZybsUsofteFXsrdjELisAVQ3/uFJi/V7td99FMgDl4t6+9CQLOTqgBQf/ozyMcCH0 Pr5Q== X-Gm-Message-State: APjAAAWX/VRtYxigMLm6INI/pf9VhIQPq+LbMW1CF6gIdhDGqTtXsXqF 9LLwSbO/KOKRY+sD6A0s2d5AdRi2MwSZ3H0oYkU2l07mBp9gCA== X-Google-Smtp-Source: APXvYqytbaq22Vle+Bgj51fETIdwhjuo9sYNd+ojqiNIxKIatJMZy+pEycaeXE7wO1fZiSfHqtNGwq/ck+8EwJLA0So= X-Received: by 2002:ab0:2789:: with SMTP id t9mr65499960uap.69.1564682471699; Thu, 01 Aug 2019 11:01:11 -0700 (PDT) In-Reply-To: <20190801164958.GH9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14492 Archived-At: --000000000000e9d135058f12060e Content-Type: text/plain; charset="UTF-8" On Thu, Aug 1, 2019 at 12:50 PM Rich Felker wrote: > > On Thu, Aug 01, 2019 at 12:15:57PM -0400, James Y Knight wrote: > > There seems to be some debate in glibc over whether this API should be > > supported, due to the long-standing debate about "pthread_t" vs > > "kernel tid" APIs. (And this API uses kernel tids, of course.) > > > > One proposal from previous glibc discussion was to add a > > SIGEV_PTHREAD_ID, which takes a pthread_t, instead of a kernel tid. > > Nobody has done this yet, and I'd note that if it is done, that is not > > at all incompatible with also continuing to support SIGEV_THREAD_ID. > > (Just like both sched_setaffinity and pthread_setaffinity_np exist > > without issue). > > > > Despite that discussion, SIGEV_THREAD_ID functionality does in fact > > work with glibc -- it provides the SIGEV_THREAD_ID define in its > > headers, and it defines the same 'struct sigevent' as the kernel does, > > including a _tid member. The only thing it's missing is the field name > > "sigev_notify_thread_id" -- so users are simply doing "#define > > sigev_notify_thread_id _sigev_un._tid" as a workaround (ugh). > > > > However, it does _not_ work today with musl, as musl's timer_create > > function translates the user-facing struct to a separate kernel-facing > > structure. > > > > Given long-standing usage of this feature, and given that potential > > future directions are additive, not conflicting, ISTM reasonable to > > just add support for this to musl. > > > From 0a0aef759f216444f558f427466b47f38d678052 Mon Sep 17 00:00:00 2001 > > From: James Y Knight > > Date: Sun, 30 Jun 2019 21:55:20 -0400 > > Subject: [PATCH] Add support for SIGEV_THREAD_ID and sigev_notify_thread_id. > > > > This is like SIGEV_SIGNAL, but targeted to a particular thread's > > tid, rather than the process. > > --- > > include/signal.h | 16 +++++++++++++--- > > src/time/timer_create.c | 8 ++++++-- > > 2 files changed, 19 insertions(+), 5 deletions(-) > > > > diff --git a/include/signal.h b/include/signal.h > > index 5c48cb83..735e0ac7 100644 > > --- a/include/signal.h > > +++ b/include/signal.h > > @@ -180,14 +180,24 @@ struct sigevent { > > union sigval sigev_value; > > int sigev_signo; > > int sigev_notify; > > - void (*sigev_notify_function)(union sigval); > > - pthread_attr_t *sigev_notify_attributes; > > - char __pad[56-3*sizeof(long)]; > > + union { > > + char __pad[64 - 2*sizeof(int) - sizeof(union sigval)]; > > + pid_t sigev_notify_thread_id; > > + struct { > > + void (*sigev_notify_function)(union sigval); > > + pthread_attr_t *sigev_notify_attributes; > > + } __sev_thread; > > + } __sev_fields; > > }; > > > > +#define sigev_notify_thread_id __sev_fields.sigev_notify_thread_id > > +#define sigev_notify_function __sev_fields.__sev_thread.sigev_notify_function > > +#define sigev_notify_attributes __sev_fields.__sev_thread.sigev_notify_attributes > > + > > I really hate these macro hacks, and have been looking at getting rid > of the ones we have (using anon unions). We don't mandate C11 to use > the public headers, but it might make sense to mandate C11 || __GNUC__ > and stick __extension__ on the struct if __GNUC__ is defined. > Unfortunately, cparser/firm prior to latest git master does not > support designated initializers right with anon unions, and GCC 3.x > doesn't either (yes, there are users of GCC 3 with musl, both > full-time and just as a bootstrapping-from-plain-C stage for distros). > So I'm not sure if we can fix this yet or just keep doing the same > nasty macro hack for now... 100% agreed! I had actually drafted the email below proposing to get rid of this in favor of C11 anonymous struct/union. However, after writing the below text, I then abandoned that idea, because _no_ version of the C++ standard supports anonymous structs -- although every version has supported anonymous unions. And I figured that because the musl headers must be parseable in C++, and given musl's goals of standards adherence, the use of a widely-supported-yet-nonstandard compiler extension would not be acceptable, even if effectively every C++ compiler in use supports it. If I was wrong about that, I'd be quite happy to use anonymous structs and unions here (and to convert the other cases as well). Unnamed struct/unions have been standardized as of C11, and was a > very-long-standing compiler extension in at least GCC, Clang, and MSVC > before that. (Looks to have been first introduced in GCC in version 3.0). > Docs https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Unnamed-Fields.html The feature makes things a bit cleaner than having to introduce #defines to > name the inner-fields, as is generally done now. Both gcc and clang accept > these unnamed, even in "-std=c89". They even accept such structs without > warning in musl headers with "-std=c89 -pedantic", since pedantic warnings > are ignored in system headers (otherwise all sorts of things like "long > long" would also warn!). Given that this feature is standard now for 8 years, and was widely > supported for decades before that, it seems that it may be a nice > simplification. On Thu, Aug 1, 2019 at 12:50 PM Rich Felker wrote: > On Thu, Aug 01, 2019 at 12:15:57PM -0400, James Y Knight wrote: > > There seems to be some debate in glibc over whether this API should be > > supported, due to the long-standing debate about "pthread_t" vs > > "kernel tid" APIs. (And this API uses kernel tids, of course.) > > > > One proposal from previous glibc discussion was to add a > > SIGEV_PTHREAD_ID, which takes a pthread_t, instead of a kernel tid. > > Nobody has done this yet, and I'd note that if it is done, that is not > > at all incompatible with also continuing to support SIGEV_THREAD_ID. > > (Just like both sched_setaffinity and pthread_setaffinity_np exist > > without issue). > > > > Despite that discussion, SIGEV_THREAD_ID functionality does in fact > > work with glibc -- it provides the SIGEV_THREAD_ID define in its > > headers, and it defines the same 'struct sigevent' as the kernel does, > > including a _tid member. The only thing it's missing is the field name > > "sigev_notify_thread_id" -- so users are simply doing "#define > > sigev_notify_thread_id _sigev_un._tid" as a workaround (ugh). > > > > However, it does _not_ work today with musl, as musl's timer_create > > function translates the user-facing struct to a separate kernel-facing > > structure. > > > > Given long-standing usage of this feature, and given that potential > > future directions are additive, not conflicting, ISTM reasonable to > > just add support for this to musl. > > > From 0a0aef759f216444f558f427466b47f38d678052 Mon Sep 17 00:00:00 2001 > > From: James Y Knight > > Date: Sun, 30 Jun 2019 21:55:20 -0400 > > Subject: [PATCH] Add support for SIGEV_THREAD_ID and > sigev_notify_thread_id. > > > > This is like SIGEV_SIGNAL, but targeted to a particular thread's > > tid, rather than the process. > > --- > > include/signal.h | 16 +++++++++++++--- > > src/time/timer_create.c | 8 ++++++-- > > 2 files changed, 19 insertions(+), 5 deletions(-) > > > > diff --git a/include/signal.h b/include/signal.h > > index 5c48cb83..735e0ac7 100644 > > --- a/include/signal.h > > +++ b/include/signal.h > > @@ -180,14 +180,24 @@ struct sigevent { > > union sigval sigev_value; > > int sigev_signo; > > int sigev_notify; > > - void (*sigev_notify_function)(union sigval); > > - pthread_attr_t *sigev_notify_attributes; > > - char __pad[56-3*sizeof(long)]; > > + union { > > + char __pad[64 - 2*sizeof(int) - sizeof(union sigval)]; > > + pid_t sigev_notify_thread_id; > > + struct { > > + void (*sigev_notify_function)(union sigval); > > + pthread_attr_t *sigev_notify_attributes; > > + } __sev_thread; > > + } __sev_fields; > > }; > > > > +#define sigev_notify_thread_id __sev_fields.sigev_notify_thread_id > > +#define sigev_notify_function > __sev_fields.__sev_thread.sigev_notify_function > > +#define sigev_notify_attributes > __sev_fields.__sev_thread.sigev_notify_attributes > > + > > I really hate these macro hacks, and have been looking at getting rid > of the ones we have (using anon unions). We don't mandate C11 to use > the public headers, but it might make sense to mandate C11 || __GNUC__ > and stick __extension__ on the struct if __GNUC__ is defined. > Unfortunately, cparser/firm prior to latest git master does not > support designated initializers right with anon unions, and GCC 3.x > doesn't either (yes, there are users of GCC 3 with musl, both > full-time and just as a bootstrapping-from-plain-C stage for distros). > So I'm not sure if we can fix this yet or just keep doing the same > nasty macro hack for now... > > Alternatively we could just put the new member in the padding since > we're translating the struct anyway, but that sacrifices glibc > ABI-compat for the newly-added feature. > > Rich > --000000000000e9d135058f12060e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 1, 2019 at 12:50 PM Rich Felker <dalias@libc.org> wrote:
>
= > On Thu, Aug 01, 2019 at 12:15:57PM -0400, James Y Knight wrote:
>= ; > There seems to be some debate in glibc over whether this API should = be
> > supported, due to the long-standing debate about "pthr= ead_t" vs
> > "kernel tid" APIs. (And this API uses= kernel tids, of course.)
> >
> > One proposal from previ= ous glibc discussion was to add a
> > SIGEV_PTHREAD_ID, which take= s a pthread_t, instead of a kernel tid.
> > Nobody has done this y= et, and I'd note that if it is done, that is not
> > at all in= compatible with also continuing to support SIGEV_THREAD_ID.
> > (J= ust like both sched_setaffinity and pthread_setaffinity_np exist
> &g= t; without issue).
> >
> > Despite that discussion, SIGEV= _THREAD_ID functionality does in fact
> > work with glibc -- it pr= ovides the SIGEV_THREAD_ID define in its
> > headers, and it defin= es the same 'struct sigevent' as the kernel does,
> > incl= uding a _tid member. The only thing it's missing is the field name
&= gt; > "sigev_notify_thread_id" -- so users are simply doing &q= uot;#define
> > sigev_notify_thread_id _sigev_un._tid" as a w= orkaround (ugh).
> >
> > However, it does _not_ work toda= y with musl, as musl's timer_create
> > function translates th= e user-facing struct to a separate kernel-facing
> > structure.> >
> > Given long-standing usage of this feature, and give= n that potential
> > future directions are additive, not conflicti= ng, ISTM reasonable to
> > just add support for this to musl.
&= gt;
> > From 0a0aef759f216444f558f427466b47f38d678052 Mon Sep 17 0= 0:00:00 2001
> > From: James Y Knight <jyknight@google.com>
> > Date: Sun, 30 Jun 2= 019 21:55:20 -0400
> > Subject: [PATCH] Add support for SIGEV_THRE= AD_ID and sigev_notify_thread_id.
> >
> > This is like SI= GEV_SIGNAL, but targeted to a particular thread's
> > tid, rat= her than the process.
> > ---
> > =C2=A0include/signal.h = =C2=A0 =C2=A0 =C2=A0 =C2=A0| 16 +++++++++++++---
> > =C2=A0src/tim= e/timer_create.c | =C2=A08 ++++++--
> > =C2=A02 files changed, 19 = insertions(+), 5 deletions(-)
> >
> > diff --git a/includ= e/signal.h b/include/signal.h
> > index 5c48cb83..735e0ac7 100644<= br>> > --- a/include/signal.h
> > +++ b/include/signal.h
= > > @@ -180,14 +180,24 @@ struct sigevent {
> > =C2=A0 =C2= =A0 =C2=A0 union sigval sigev_value;
> > =C2=A0 =C2=A0 =C2=A0 int = sigev_signo;
> > =C2=A0 =C2=A0 =C2=A0 int sigev_notify;
> &g= t; - =C2=A0 =C2=A0 void (*sigev_notify_function)(union sigval);
> >= ; - =C2=A0 =C2=A0 pthread_attr_t *sigev_notify_attributes;
> > - = =C2=A0 =C2=A0 char __pad[56-3*sizeof(long)];
> > + =C2=A0 =C2=A0 u= nion {
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 char __pad[= 64 - 2*sizeof(int) - sizeof(union sigval)];
> > + =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 pid_t sigev_notify_thread_id;
> > + = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
> > + =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 void (*sigev= _notify_function)(union sigval);
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pthread_attr_t *sigev_notify_att= ributes;
> > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } __sev_t= hread;
> > + =C2=A0 =C2=A0 } __sev_fields;
> > =C2=A0};> >
> > +#define sigev_notify_thread_id __sev_fields.sigev= _notify_thread_id
> > +#define sigev_notify_function __sev_fields.= __sev_thread.sigev_notify_function
> > +#define sigev_notify_attri= butes __sev_fields.__sev_thread.sigev_notify_attributes
> > +
&= gt;
> I really hate these macro hacks, and have been looking at getti= ng rid
> of the ones we have (using anon unions). We don't mandat= e C11 to use
> the public headers, but it might make sense to mandate= C11 || __GNUC__
> and stick __extension__ on the struct if __GNUC__ = is defined.
> Unfortunately, cparser/firm prior to latest git master = does not
> support designated initializers right with anon unions, an= d GCC 3.x
> doesn't either (yes, there are users of GCC 3 with mu= sl, both
> full-time and just as a bootstrapping-from-plain-C stage f= or distros).
> So I'm not sure if we can fix this yet or just kee= p doing the same
> nasty macro hack for now...

100% agreed!=C2= =A0

I had actually drafted the email below proposing to = get rid of this in favor of C11 anonymous struct/union. However, after writ= ing the below text, I then abandoned that idea, because _no_ version of the= C++ standard supports anonymous structs -- although every version has supp= orted anonymous unions. And I figured that because the musl headers must be= parseable in C++, and given musl's goals of standards adherence, the u= se of a widely-supported-yet-nonstandard compiler extension would not be ac= ceptable, even if effectively every C++ compiler in use supports it.
<= div>
If I was wrong about that, I'd be quite happy to use= anonymous structs and unions here (and to convert the other cases as well)= .

Unnam= ed struct/unions have been standardized as of C11, and was a very-long-stan= ding compiler extension in at least GCC, Clang, and MSVC before that. (Look= s to have been first introduced in GCC in version 3.0). Docs https://gcc.= gnu.org/onlinedocs/gcc-4.7.2/gcc/Unnamed-Fields.html=C2=A0
=
=C2=A0
The feature makes things a bit = cleaner than having to introduce #defines to name the inner-fields, as is g= enerally done now. Both gcc and clang accept these unnamed, even in "-= std=3Dc89". They even accept such structs without warning in musl head= ers with "-std=3Dc89 -pedantic", since pedantic warnings are igno= red in system headers (otherwise all sorts of things like "long long&q= uot; would also warn!).=C2=A0
=C2=A0
Given that this feature is standard now for 8 years, and was wid= ely supported for decades before that, it seems that it may be a nice simpl= ification.


On Thu, Aug 1, 2019 at 12:50 PM Rich Felke= r <dalias@libc.org> wrote:
=
On Thu, Aug 01, 201= 9 at 12:15:57PM -0400, James Y Knight wrote:
> There seems to be some debate in glibc over whether this API should be=
> supported, due to the long-standing debate about "pthread_t"= vs
> "kernel tid" APIs. (And this API uses kernel tids, of course= .)
>
> One proposal from previous glibc discussion was to add a
> SIGEV_PTHREAD_ID, which takes a pthread_t, instead of a kernel tid. > Nobody has done this yet, and I'd note that if it is done, that is= not
> at all incompatible with also continuing to support SIGEV_THREAD_ID. > (Just like both sched_setaffinity and pthread_setaffinity_np exist
> without issue).
>
> Despite that discussion, SIGEV_THREAD_ID functionality does in fact > work with glibc -- it provides the SIGEV_THREAD_ID define in its
> headers, and it defines the same 'struct sigevent' as the kern= el does,
> including a _tid member. The only thing it's missing is the field = name
> "sigev_notify_thread_id" -- so users are simply doing "= #define
> sigev_notify_thread_id _sigev_un._tid" as a workaround (ugh).
>
> However, it does _not_ work today with musl, as musl's timer_creat= e
> function translates the user-facing struct to a separate kernel-facing=
> structure.
>
> Given long-standing usage of this feature, and given that potential > future directions are additive, not conflicting, ISTM reasonable to > just add support for this to musl.

> From 0a0aef759f216444f558f427466b47f38d678052 Mon Sep 17 00:00:00 2001=
> From: James Y Knight <jyknight@google.com>
> Date: Sun, 30 Jun 2019 21:55:20 -0400
> Subject: [PATCH] Add support for SIGEV_THREAD_ID and sigev_notify_thre= ad_id.
>
> This is like SIGEV_SIGNAL, but targeted to a particular thread's > tid, rather than the process.
> ---
>=C2=A0 include/signal.h=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 16 +++++++++++++--= -
>=C2=A0 src/time/timer_create.c |=C2=A0 8 ++++++--
>=C2=A0 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/include/signal.h b/include/signal.h
> index 5c48cb83..735e0ac7 100644
> --- a/include/signal.h
> +++ b/include/signal.h
> @@ -180,14 +180,24 @@ struct sigevent {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0union sigval sigev_value;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0int sigev_signo;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0int sigev_notify;
> -=C2=A0 =C2=A0 =C2=A0void (*sigev_notify_function)(union sigval);
> -=C2=A0 =C2=A0 =C2=A0pthread_attr_t *sigev_notify_attributes;
> -=C2=A0 =C2=A0 =C2=A0char __pad[56-3*sizeof(long)];
> +=C2=A0 =C2=A0 =C2=A0union {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char __pad[64 - 2*siz= eof(int) - sizeof(union sigval)];
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pid_t sigev_notify_th= read_id;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0void (*sigev_notify_function)(union sigval);
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0pthread_attr_t *sigev_notify_attributes;
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} __sev_thread;
> +=C2=A0 =C2=A0 =C2=A0} __sev_fields;
>=C2=A0 };
>=C2=A0
> +#define sigev_notify_thread_id __sev_fields.sigev_notify_thread_id > +#define sigev_notify_function __sev_fields.__sev_thread.sigev_notify_= function
> +#define sigev_notify_attributes __sev_fields.__sev_thread.sigev_notif= y_attributes
> +

I really hate these macro hacks, and have been looking at getting rid
of the ones we have (using anon unions). We don't mandate C11 to use the public headers, but it might make sense to mandate C11 || __GNUC__
and stick __extension__ on the struct if __GNUC__ is defined.
Unfortunately, cparser/firm prior to latest git master does not
support designated initializers right with anon unions, and GCC 3.x
doesn't either (yes, there are users of GCC 3 with musl, both
full-time and just as a bootstrapping-from-plain-C stage for distros).
So I'm not sure if we can fix this yet or just keep doing the same
nasty macro hack for now...

Alternatively we could just put the new member in the padding since
we're translating the struct anyway, but that sacrifices glibc
ABI-compat for the newly-added feature.

Rich
--000000000000e9d135058f12060e--