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

[via libc-commits]

enh-google wrote:

> > shouldn't __sighandler_t come from the uapi header,
> 
> Did you mean `__signalfn_t`? It looks like asm-generic/signal-defs.h depends on `__sighandler_t`, but they themselves do not define that typedef. (unless something is really 
wrong with my grep-fu).

not in AOSP's clean copy (external/kernel-headers/). it's just split in two for readability (though i feel like the `__user` destroys that), but they're on adjacent lines in the file you mentioned:
```
typedef void __signalfn_t(int);
typedef __signalfn_t __user *__sighandler_t;
```

> > and only if you're using the uapi headers?
> 
> We're inconsistent about our use of uapi headers. I would like to try to use them more, but I suspect most libcs have run into issues with the uapi headers. Probably a longer conversation to have there...

yeah, they're kind of a mess, with some hacks for glibc compatibility (which is weird because glibc copy & pastes instead; bionic and musl compatibility would make more sense!). but, yes, if a side-effect of llvm-libc was making the uapi headers a bit less direct-libc-use-hostile, that would be good.

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