No, it's very common for them to be written in primarily C. But I'm obligated to mention (as a member of the Rust Evangelism Strike Force) that you don't have to write them in C. ;)

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.

> No, it's very common for them to be written in primarily C

Then can't you just get the LLVM IR out of it using Clang?

The root of the issue is that, while you can write most of the code in C (but not all), it has to be different for different operating system kernels. It will use different syscall numbers, argument size and order and "extra options" will be different, some kernels will have a more general syscall with options that enable it to be used for a handful of similar standard libc wrapper functions ...

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.

I think that's immaterial but you're right that you could dump the IR.

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.

Somebody has to write the library to begin with. The typical Unix thing is for the OS to have one everybody links to. Which means, among other things, variation between libcs is a factor in portability of C programs from one OS to another.