On Thu, Aug 22, 2024 at 1:34 PM enh <enh@xxxxxxxxxx> wrote: > > On Thu, Aug 22, 2024 at 12:57 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > > > Hi Elliott, > > > > On Thu, Aug 22, 2024 at 12:34:11PM GMT, enh wrote: > > > On Thu, Aug 22, 2024 at 12:27 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > > > I'd rather add a diagnostic for those who define it themselves now, > > > > than providing a sub-par prototype for eternity. I guess the existing > > > > number of users is small, and it doesn't break binaries, just > > > > compilation. > > > > > > yeah, afaict it's basically just "qemu-like things" and the occasional > > > debugging tool. > > > > > > > Those will probably just need to add an ifdef for the glibc version that > > > > added the prototype, so it's an easy fix. > > > > > > no, they'd just have to change their declaration to match whatever > > > glibc ships. (which is definitely more verbose if it's any kind of > > > union.) > > > > Redefinition of transparent unions is allowed? I'm not sure; at least > > prior to C23. > > huh. i did not know that. "works for me" on clang, anyway, and seems > like a good argument for the transparent union... > > i took a more careful look at the code i can easily search, and i found: > > 1. extern int arch_prctl(int, unsigned long); > the most common choice, presumably popularized by the kernel source > and the man page. > 2. extern int arch_prctl(int, uintptr_t); > much less common, and compatible with option 1 anyway. > 3. extern int arch_prctl(int, unsigned long*); > very rare, but used in compiler-rt for tsan (and at least a gcc > hwasan tests?). > 4. extern int arch_prctl(int, unsigned long int); > if you're not into the whole brevity thing. > > so actually the transparent union is the only thing that's source > compatible with all the existing code [in the corpus i have easy > access to]. ...except transparent unions are C-only, so we'd need something else for C++ if we went with this for C. > > > i don't have a strong opinion, other than "i want to make sure that > > > bionic and glibc have the _same_ declaration so that it's at least > > > possible for folks to fix their source to 'just work' everywhere"... > > > > +1 > > > > > > But I tend to value more eternity than added diagnostics, and others may > > > > disagree with that, so whatever you decide is probably good, and I'll > > > > document it. :) > > > > > > minimizing the need for changes on the man page is also a [minor] > > > argument for just going with the kernel declaration :-) > > > > > > plus it's demonstrably "good enough" for existing callers. it's not > > > like the union would make the api any less error-prone? > > > > The union removes the need for a cast. The cast is error-prone, since > > it disables most compiler diagnostics. > > > > Cheers, > > Alex > > > > -- > > <https://www.alejandro-colomar.es/>
