Furthermore, when this work is combined with the recent std.Io changes, there is potential for users to seamlessly control how libc performs I/O - for example forcing all calls to read and write to participate in an io_uring event loop, even though that code was not written with such use case in mind. Or, resource leak detection could be enabled for third-party C code. For now this is only a vaporware idea which has not been experimented with, but the idea intrigues me.

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.)