Yeah, I am also confused. Isn't there Clang already?
(Please correct me if I am wrong)
The C library provides implementations for the platform-neutral language functions like "open/read/write/close/ioctl/dup/dup2" and more.
Many implementations do have performance-critical parts be target-dependent and implemented in assembly. IIRC glibc has more of this than musl/newlib/bionic, but it's been a while since I last looked.
Then can't you just get the LLVM IR out of it using Clang?
For the most part, C is a much easier language to program in than the IR. The IR is also very unstable: it changes from release to release.
On macOS, you're really supposed to always dynamically link to the libSystem.dylib libc implementation, because the macOS kernel has subtle backwards-incompatible changes in the raw syscall interfaces on every macOS release (maybe even in point-release updates, I'm not sure). Go tried to have its own internal static libc replacement for macOS like it does for Linux, but just a year or two ago Go gave that up, and now dynamically links the macOS libc.
These are all syscall wrappers. They are present in libc but they are going to be very boring stubs that merely call into the kernel. (Also I don't think you can call them platform neutral or language functions as they are POSIX rather than being from the C standard...)
The more "implementation-heavy" parts of a libc... Things like stdio, string calls, malloc, ...
Some of them also have to translate between the userspace version of particular argument types and the kernel version, which don't always line up.
> you can implement it yourself via signals
It appears, that you are contradicting yourself. Either it is "bad idea" or it is easy to correctly implement by oneself, not both.
musl has well though-out implementation of pthread cancellation, so it is clearly doable, even if glibc developers have failed at it.
It's easy to correctly implement the parts that aren't just adding a call to pthread_testcancel to every single syscall wrapper, just reserve an RT signal and do your thread teardown when you receive it, using pthread_sigmask to implement enable/disable. It's just that it's just a terrible idea.
> is a giant minefield if you care about not leaking or deadlocking
Aren't these two in opposition?
Libc is the C standard library, and there are multiple implementations of it, e.g. glibc and musl. Clang does not include an implementation of libc, though it does have an implementation of the C++ standard library called libc++: https://libcxx.llvm.org/
It's not immediately clear to me why an LLVM implementation of the C++ standard library would be desirable while an implementation of the C standard library would be undesirable.
Worth noting the c++ standard library has had a lot of changes in recent years. libc has been hugely more stable in the same timeframe. (Notably there was C11, but the changes since C99 are not nearly what has been going on in c++ land.) The odds that whatever libc you already have is good enough are very high.