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

[Nick Desaulniers 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__
----------------
nickdesaulniers 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).

---

> but _GNU_SOURCE is something developers are used to turning on/off either via -std=gnu23 vs -std=c23

Wait...what?!

```sh
$ 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!?

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