lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 May 2020 16:57:56 +0200 From: Florian Weimer <fweimer@...hat.com> To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com> Cc: libc-alpha <libc-alpha@...rceware.org>, Rich Felker <dalias@...c.org>, linux-api <linux-api@...r.kernel.org>, Boqun Feng <boqun.feng@...il.com>, Will Deacon <will.deacon@....com>, linux-kernel <linux-kernel@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org>, Ben Maurer <bmaurer@...com>, Dave Watson <davejwatson@...com>, Thomas Gleixner <tglx@...utronix.de>, Paul <paulmck@...ux.vnet.ibm.com>, Paul Turner <pjt@...gle.com>, Joseph Myers <joseph@...esourcery.com> Subject: Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v19) * Mathieu Desnoyers: >> Like the attribute, it needs to come right after the struct keyword, I >> think. (Trailing attributes can be ambiguous, but not in this case.) > > Nope. _Alignas really _is_ special :-( > > struct _Alignas (16) blah { > int a; > }; > > p.c:1:8: error: expected ‘{’ before ‘_Alignas’ > struct _Alignas (16) blah { Meh, yet another unnecessary C++ incompatibility. C does not support empty structs, so I assume they didn't see the field requirement as a burden. > One last thing I'm planning to add in sys/rseq.h to cover acessing the > rseq_cs pointers with both the UAPI headers and the glibc struct rseq > declarations: > > /* The rseq_cs_ptr macro can be used to access the pointer to the current > rseq critical section descriptor. */ > #ifdef __LP64__ > # define rseq_cs_ptr(rseq) \ > ((const struct rseq_cs *) (rseq)->rseq_cs.ptr) > #else /* __LP64__ */ > # define rseq_cs_ptr(rseq) \ > ((const struct rseq_cs *) (rseq)->rseq_cs.ptr.ptr32) > #endif /* __LP64__ */ > > Does it make sense ? Written this way, it's an aliasing violation. I don't think it's very useful. Thanks, Florian
Powered by blists - more mailing lists