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

[via libc-commits]

================
@@ -0,0 +1,17 @@
+//===-- Definition of sighandler_t ----------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_LIBC_TYPES_SIGHANDLER_T_H
+#define LLVM_LIBC_TYPES_SIGHANDLER_T_H
+
+#ifdef __linux__
----------------
enh-google wrote:

> I was thinking more about this last night, and `qsort_r` came to mind.
> 
> So I guess I should change my stance slightly from "never" to "perhaps when there _is_ a conflict."
> 
> Is there a conflict here? Well, `sig_t` and `sighandler_t` don't conflict with each other, and the issue isn't as severe as `qsort_r`. But Bionic provides both without requiring users to pledge allegiance; if bionic doesn't llvm-libc should not either (IMO).
> 
> > I learned it from you, Dad! /runs away crying
> 
> But I will keep that in mind that `_GNU_SOURCE` and `_BSD_SOURCE` do exist more for than just pledges of allegiance and holding user code hostage, and that we may need to deploy those in llvm-libc in the future. I still don't think we need to here (yet; famous last words).

yeah, as you can probably tell, i do think "provide all the things until/unless proven problematic" is a developer-friendly option.

the only real counterargument i've heard is "it's bad for source portability in the _other_ direction". but i've always cared more that people's stuff "just works" when ported _to_ the libc i have control over rather than what might happen when ported _away_ (in part because that's probably less common anyway; any library that's first developed on Android seems likely to be Android-specific in some way, or you'd probably make it cross-platform from the beginning).

> > but _GNU_SOURCE is something developers are used to turning on/off either via -std=gnu23 vs -std=c23
> 
> Wait...what?!
> 
> ```shell
> $ clang -std=gnu++23 --target=x86_64-linux-gnu -dM -E -x c++ /dev/null | grep GNU_SOURCE
> #define _GNU_SOURCE 1
> $ clang -std=gnu23 --target=x86_64-linux-gnu -dM -E -x c /dev/null | grep GNU_SOURCE
> $ g++ -dM -E -x c++ /dev/null | grep GNU_SOURCE
> #define _GNU_SOURCE 1
> $ gcc -dM -E -x c /dev/null | grep GNU_SOURCE
> $
> ```
> 
> uh...so perhaps not a bug in clang as the first two statements made me think...but WTF!?

oh, yeah, that's it ... i never do this myself, so i can never remember _which_ combinations imply `_GNU_SOURCE`, just that there are dragons in that area.

madness indeed. (especially because `gnu` vs `c` _does_ let you opt in/out of _language_ extensions. if you were going to do anything here, consistency would have been nice. i assume there was a historical accident somewhere -- like bionic's always-on `_BSD_SOURCE` and they just couldn't fix it by the time they realized.)

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