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]. > > 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/>
