diff options
| author | Alex Rønne Petersen <alex@alexrp.com> | 2025-04-10 19:17:29 +0200 |
|---|---|---|
| committer | Alex Rønne Petersen <alex@alexrp.com> | 2025-04-11 17:12:31 +0200 |
| commit | 1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed (patch) | |
| tree | 66d5586f636c37b65a1b99de3c0665bab97ec3f0 /lib/libtsan/interception/interception_mac.cpp | |
| parent | ee0ff134e9f82bf87751a5174c27b191c04e16c0 (diff) | |
| download | zig-1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed.tar.gz zig-1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed.zip | |
Introduce libzigc for libc function implementations in Zig.
This lays the groundwork for #2879. This library will be built and linked when a
static libc is going to be linked into the compilation. Currently, that means
musl, wasi-libc, and MinGW-w64. As a demonstration, this commit removes the musl
C code for a few string functions and implements them in libzigc. This means
that those libzigc functions are now load-bearing for musl and wasi-libc.
Note that if a function has an implementation in compiler-rt already, libzigc
should not implement it. Instead, as we recently did for memcpy/memmove, we
should delete the libc copy and rely on the compiler-rt implementation.
I repurposed the existing "universal libc" code to do this. That code hadn't
seen development beyond basic string functions in years, and was only usable-ish
on freestanding. I think that if we want to seriously pursue the idea of Zig
providing a freestanding libc, we should do so only after defining clear goals
(and non-goals) for it. See also #22240 for a similar case.
Diffstat (limited to 'lib/libtsan/interception/interception_mac.cpp')
0 files changed, 0 insertions, 0 deletions
