[libc-commits] [libc] [libc] Support configurable errno modes (PR #98287)

[Roland McGrath via libc-commits]

================
@@ -1,4 +1,10 @@
 {
+  "errno": {
+    "LIBC_CONF_ERRNO_MODE": {
+      "value": "",
+      "doc": "The implementation used for errno, acceptable values are LIBC_ERRNO_MODE_NONE, LIBC_ERRNO_MODE_INTERNAL, LIBC_ERRNO_MODE_EXTERNAL, LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_GLOBAL, and LIBC_ERRNO_MODE_SYSTEM."
----------------
frobtech wrote:

Today's "baremetal" is a very specific set of choices about an embedded-style use case.  I'm confident that there will in the long run be embedded-style use cases that are purely single-threaded and want to avoid the overhead (or need for useless libcall stubs that do nothing) of atomics.  I think it will certainly be the right thing for all libc code that might ever be useful in some minimal embedded context to be configurable to avoid atomics at the cost of any kind of thread safety.  I don't think it will ever be wise enough to be acceptable to "achieve" that via hacks like `-DLIBC_THREAD_LOCAL=` or making `cpp::Atomic` configurable to itself not actually be atomic.  Instead, I think each and every case (so far, `rand` and `errno`) merits its own intentional and explicit configuration choice so in each context someone has to decide what semantics, and tradeoffs between formally standards-compliant  and/or de facto norm semantics and other context-specific factors, are right for them.

For today, it doesn't matter if we support everything that we should in principle support in terms of configuration options.  The taxonomy above I think covers all the options for `errno` in particular that I anticipate we will support long term.  The subset of `THREAD_LOCAL`, `SHARED_ATOMIC`, and `SHARED_THREAD_UNSAFE` is probably a common vocabulary that makes sense for the broader general class of cases that includes `rand`, while the other options here are idiosyncratic to `errno`.

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