Open andrewrk opened 5 years ago
We now ship libc++ as well and it offers even more opportunities for this.
I think we should focus on musl first especially stuff that does not rely on syscall. That should cover most targets easily as there are very few issues to to use does functions with ucrt for example.
Is there anything that needs doing here that would be somewhat 'newcomer friendly'? Looking for an opportunity to get involved in something a bit bigger than zig fmt fixes :)
@LewisGaul add *BSD libc issues?
@nektro has a draft PR for FreeBSD: #8327
I was looking at this for something similar recently. So I have some points so we can create a more concrete plan.
First thing, to what extend are we replacing the functions, are we only going to be doing only ones we have access to source or we can we do for one we only have headers or even no source at all? On nice thing if we can patch header is we can add functions not found in one libc but found in another one (annex k and complex numbers and C2x).
Unless we can do vardic functions in zig, we will not be able to stdio as printf family of function are vardic functions. Alot functions are simply wrapper here so we can share a lot of but it must implemented in c.
We should use the structure implemented in the libc and not reimplement it not to break the ABI. To us they should be an opaque structure. No need reimplement them.
Some stuff need state or a "runtime" like malloc and threads. Locale id the most annoying here. So unless we don't mind short circuiting locales, lets not touch those. We can still implementing supprising amount of functions though.
There are alot of function especially the math one which doesn't even need a libc itself. We really should start implementing this part first along with the wrappers in place like stdio. If done correctly we could even safety link some of these functions to any executable on any target.
is this with the intent to eventually remove some of the header files?
The "freestanding"/platform-independent bits are covered either by std.math or compiler-rt, see https://github.com/ziglang/zig/issues/7265.
What remains are smaller or bigger platform dependencies, which ideally have automatic abi tracking per platform or at least some test coverage for each supported platform.
Some of the shennanigans I did experience on trying to build a sane test system (it is not possible without user input for "non-standard platforms/freestanding"):
There are several things missing in the proposal to estimate the scope:
char
can be signed or unsigned.Technical side questions:
Related: https://github.com/marler8997/ziglibc/issues/1 Also related (to check if upstream breaks abi or allows abi breakage via build scripts etc): https://github.com/ziglang/zig/pull/11447 see posix_spawn as example, which can be platform defined (and for some reason glibc doesnt want to upstream the logic).
I played around with C macro introspection here and I believe that C code can not be sanely argued on without assumptions on how symbols may be retrieved for target triplet, all used types (typedefs offer no simple introspection) and a bunch of "platform specifiers" (super basic assumptions like function exit codes etc).
Some libc functions can obviously share a common implementation. For example, right now, musl, mingw, the zig standard library all have independent implementations of the math functions, such as
sqrt
.Instead, the canonical implementation should be in Zig, and even when providing musl or mingw libcs, the zig code should be built and used to fulfill those dependencies.
Other examples of functions would be
memcpy
andstrcmp
.Functions that would be tricky to have common implementations would be, e.g.
fopen
. But that's worth investigating as well.