zig libc
181 points by kwas
181 points by kwas
Great news. C today is not only a language, but a protocol. Having more independent implementations will eventually lead to a better protocol.
This is good!
I've been messing with Zig for the last month. Great stuff. Definitely a better "C".
...Abolish ICE.
Will this be like Go, that Zig has it's own libc on some platforms and others not?
We necessarily can't bring our own libc on platforms like macOS or Linux w/ glibc. There you'll be using the system libc at the end of the day (though of course we support cross-compiling for it).
The immediate goal is to replace all the C code we bundle from musl, wasi-libc, and MinGW-w64 with Zig code. So if you cross-compile for those libcs with static linking, you get Zig's libc which is API/ABI-compatible. In the future, it's entirely possible that we could expand the scope of Zig's libc to also be API/ABI-compatible with the statically-linked libcs from FreeBSD, NetBSD, etc. (We don't currently bundle the static C code for those.)
Are you saying that if ask Zig for musl, I might not actually get musl? That seems a little strange to me. Has any consideration been given to providing an option to target actual musl as opposed to the vendored libc?
Does it matter if it's indistinguishable from actual musl in terms of API, ABI, and behavior?
In general, I suspect not, though that "if" is doing a lot of heavy lifting. Unfortunately, we don't live in a perfect world, and in the event that zig-libc and musl ever diverged by accident (e.g. one of them having a bug that the other lacks), it could become an issue.
I think mostly, though, it's surprising behavior. Musl is a specific libc implementation. If I ask Zig for a static libc, and it happens to give me musl or zig-libc or something else, that's one thing. If I ask for musl, and I don't get musl, that's a very different thing. Having my tools second-guess my decisions often leads to a bad time, in my experience.
In general, I suspect not, though that "if" is doing a lot of heavy lifting. Unfortunately, we don't live in a perfect world, and in the event that zig-libc and musl ever diverged by accident (e.g. one of them having a bug that the other lacks), it could become an issue.
In most cases, the bug would be in Zig's libc then.
An exception might be if it's behavior that musl doesn't consider well-defined, in which case the bug is in the application, and whether we'd change Zig libc to match would probably be handled on a case-by-case basis. In general I suspect we wouldn't, but of course in the real world, bugs and quirks do sometimes become features if enough software depends on them.
I think mostly, though, it's surprising behavior. Musl is a specific libc implementation. If I ask Zig for a static libc, and it happens to give me musl or zig-libc or something else, that's one thing. If I ask for musl, and I don't get musl, that's a very different thing. Having my tools second-guess my decisions often leads to a bad time, in my experience.
This isn't quite the view we take. When you say e.g. aarch64-linux-musl, we interpret that as "target the AArch64 architecture, a Linux-compatible operating system, and a musl-compatible libc". In all of this, we have no idea if you'll actually run your program on a real AArch64 CPU or in an emulator. Or if you'll run it against real Linux or FreeBSD's Linux compatibility layer.
If you're dynamically linking your program, you also have no idea if the libc ld.so that interprets your program actually is the libc you compiled against, or just something that's compatible.
If you continue down this line of thought, it's not too crazy that asking for static musl gets you something that looks and walks and talks like static musl, but just isn't literally the same C source code as found on musl.libc.org.
(Also, keep in mind that you could always use --libc musl.txt if you really did want to use actual musl.)
It seems strange to me that a language that’s so built around developer control would circumvent explicit choices. I’d worry about this especially given Hyrum’s law, which I imagine would apply more to libc than almost anything else due to widespread use and how much the implementation details leak outside of the API surface area. Like, will zig-libc forever reproduce musl’s somewhat strange DNS resolution?