[libc-commits] [libc] [libc][signal] clean up usage of sighandler_t (PR #125745)

[via libc-commits]

enh-google wrote:

> Regardless, looking at the usage of `__sighandler_t` in asm-generic/signal-defs.h, I suspect that the libc is expected to provide the typedef to the kernel uapi header (which seems ass-backwards to me, but perhaps there's a good reason I'm unfamiliar with). (Also, perhaps I should just send a kernel patch to just use `void (*member)(int);` then in 100 years we can depend on it).

i wasn't involved in the upstream uapi stuff, but as a _user_ of the uapi headers i've always assumed the opposite: that they deliberately use "not quite the names" to avoid conflicts with userspace. (it seems obvious that they _try_ somewhat, even if they're not particularly successful/systematic.)

> So I worry about a (hypothetical, perhaps contrived) case where: a user of llvm-libc somehow manages to `#include <asm-generic/signal.h>` before include llvm-libc's `<signal.h>` such that `__sighandler_t` is not defined. Because the kernel headers themselves do not define `__sighandler_t`, that results in a compilation failure since there is no definition of `__sighandler_t`. Is that possible? Or something else I'm misssing?

i still claim you're wrong there --- my unadulterated copy of the uapi headers _does_ define `__sighandler_t`, as i copy & pasted above and will repeat here:
```
typedef void __signalfn_t(int);
typedef __signalfn_t __user *__sighandler_t;
```
and i think -- without ever having talked to anyone responsible -- this is the whole point of all these double-underscore "almost right" names; they want things to "just work" wherever possible, without accidentally getting in the way.

(it's perhaps worth mentioning that it's very spotty. one of the main things we do when transforming the uapi headers from their upstream form to the form included in bionic is that we do a lot of "replace struct/type with a #include of our corresponding <bits/...> file" so we can have consistent behavior in all the cases the uapi headers _didn't_ think about. as i think i already mentioned, glibc mainly gets by with copy & paste, and musl seems to be on its usual "don't do that then" side of the fence.)

https://github.com/llvm/llvm-project/pull/125745