# Introduce libzigc for libc function implementations in Zig\. · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: 1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed

Requested commit: 1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed

Commit: 1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed

Tree: 66d5586f636c37b65a1b99de3c0665bab97ec3f0

Author: Alex Rønne Petersen

Committer: Alex Rønne Petersen

## Message

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

```

## Parents

- [ee0ff134e9f82bf87751a5174c27b191c04e16c0](https://git.cafe/gitcafe/zig/commit/ee0ff134e9f82bf87751a5174c27b191c04e16c0?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/1f896c1bf89aa0e3d2a0dce1f4cf6ba6ce5ae9ed?format=markdown)