[libc-commits] [libc] [libc][signal] clean up usage of sighandler_t (PR #125745)
Nick Desaulniers via libc-commits
libc-commits at lists.llvm.org
Thu Feb 6 13:53:18 PST 2025
================
@@ -10,5 +10,6 @@
#define LLVM_LIBC_TYPES___SIGHANDLER_T_H
typedef void (*__sighandler_t)(int);
----------------
nickdesaulniers wrote:
> i'm just trying to brain dump as much of the bionic history as i can, in particular when we have things that went well vs things that went badly (and orthogonally things we did on purpose vs things that were accidents).
Having that in writing and documented is appreciated; especially handy to be able to link to in the future.
> (and your yaml format doesn't work well for examples like signal() :-P )
Did you just call my baby ugly? :P
> bionic's default "never duplicate something that's in a uapi header" policy
> maybe that's more likely now between your kernel connections and there now [maybe] being two libcs that want to not duplicate anything that's in a uapi header and the existing glibc "it would be nice if you could include the glibc header and the uapi header without conflicts".
Right! I plan to do more research into why this is a problem, and what various kernel developers and libc maintainers view as the problems. I suspect we can clean this up upstream in the kernel sources for everyone (that matters).
> yeah, don't mind me ...
May I have +2 then from you? I think my fellow reviewers are watching this from the sidelines and deferring to your experience here.
https://github.com/llvm/llvm-project/pull/125745
More information about the libc-commits
mailing list