Why doesn't this work

I like musl, especially the well-written source code, and think it would be an improvement if everyone used it. I just don't agree with this "kernel interface is libc" thing on principle.

The actual Linux kernel-to-user space interface are the assembly entry points; they're architecture-dependent and programming language-agnostic. They shouldn't be hidden away behind some libc whose maintainers don't even like adding Linux-specific system calls to its own API because of muh Unix compatibility. Also, why C? What about other languages? It's a polyglot world out there; they could easily use JIT compilation to dynamically generate code to perform system calls. Why must they be prevented from doing that just to avoid screwing up glib's global state?

I think this deserves more attention.


That's just the thing. If I ask for the manual pages about the Linux system calls, they give me the glibc pages that document the system call wrappers. It's insane if you ask me. It's about as insane as giving me documentation on systemd when I ask for the init system documentation. Why isn't there a page detailing the requirements Linux imposes on all init systems? I'm accessing the Linux kernel manuals yet it gives me user space manual pages.

These things are for some reason deeply entrenched in Linux. So entrenched, the kernel people apparently assume you're using them. It's kinda hard to move away from GNU when people program on top of glib rather than Linux.

People use GCC, GlibC, and GNU extensions because they actually like these features. If they didn't think it was useful, they would obviously not be using it. Nobody is writing software in the C language without the background knowledge that GNU extensions to the C language are not officially ratified by the ISO C language body.

I don't mind GNU extensions to the language. Actually I think they're extremely useful. I don't really care very much what C standards have to say, I care about what compilers do.

stackoverflow.com/q/48731306

>It can then further prove that i < 300 is always true, and so the loop condition can be optimized away.

Undefined behavior claims yet another unsuspecting victim.