【Zig 日报】Zig libc

[jiacai2050]

作者：Andrew Kelley

在过去的一个月左右的时间里，几位积极进取的贡献者对 zig libc 子项目产生了兴趣。这里的想法是，通过提供作为 Zig 标准库封装的 libc 函数，而不是作为供应商提供的 C 源代码文件，来逐步删除冗余代码。在许多情况下，这些函数是一对一的映射，例如 memcpy 或 atan2，或者只是简单地封装了一个通用函数，例如 strnlen：

fn strnlen(str: [*:0]const c_char, max: usize) callconv(.c) usize {
    return std.mem.findScalar(u8, @ptrCast(str[0..max]), 0) orelse max;
}

到目前为止，大约 250 个 C 源代码文件已从 Zig 仓库中删除，还剩下 2032 个。

每当一个函数完成这种转换，Zig 就会增加对第三方项目和 C 编程语言的独立性，编译速度得到提高，Zig 的安装大小得以简化和减小，并且静态链接 libc 的用户应用程序也享受到更小的二进制文件大小。

此外，最近的一项增强功能现在使得 zig libc 与其他 Zig 代码共享 Zig 编译单元（Zig Compilation Unit），而不是作为一个单独的静态归档文件在稍后才链接。这是 Zig 拥有集成编译器和链接器的优势之一。当导出的 libc 函数共享 ZCU 时，冗余代码会被消除，因为函数可以一起进行优化。这有点像在 libc 边界上启用了 LTO（链接时优化），只不过它是在前端正确完成的，而不是在链接器中为时已晚。

此外，当这项工作与最近的 std.Io 更改结合起来时，用户有可能无缝地控制 libc 如何执行 I/O——例如，强制所有对 read 和 write 的调用都参与到 io_uring 事件循环中，即使这些代码在编写时并没有考虑到这样的用例。或者，可以为第三方 C 代码启用资源泄漏检测。目前这只是一个尚未进行实验的空中楼阁般的想法，但这个想法让我很感兴趣。

非常感谢 Szabolcs Nagy 的 libc-test。这个项目对于确保我们没有导致任何数学函数退化方面提供了巨大的帮助。

提醒我们的用户，既然 Zig 正在过渡到成为静态 libc 提供者，如果您遇到由 Zig 提供的 musl、mingw-w64 或 wasi-libc 的 libc 功能问题，请首先在 Zig 中提交错误报告，这样我们就不会因为 Zig 中的错误而烦扰维护者，这些错误不再是由独立的 libc 实现项目提供的。

Abolish ICE.（废除 ICE。）

译者注："ICE" 通常指美国移民和海关执法局（U.S. Immigration and Customs Enforcement）。关于“废除 ICE”的讨论是美国政治中的一项争议性议题。

加入我们

Zig 中文社区是一个开放的组织，我们致力于推广 Zig 在中文群体中的使用，有多种方式可以参与进来：

1. 供稿，分享自己使用 Zig 的心得
2. 改进 ZigCC 组织下的开源项目
3. 加入微信群、Telegram 群组