与POSIX兼容的操作系统通常扩展C标准库的现有实现？

POSIX声明，要使操作系统符合POSIX标准，需要提供的功能单元之一是POSIX_C_LANG_支持。基本上，这是一个完整的C标准库，还有更多的东西

我的问题很简单：与POSIX兼容的操作系统的开发人员通常只需下载C标准库的开源版本（例如glib或uClibc），并对其进行调整以适应POSIX，或者他们从头开始实现一切？重写C库而不是仅仅选择一个非常著名的实现并根据我的需要进行调整有什么好处吗？

好吧，我们都是站在巨人肩膀上的矮人

---

编写一个新的操作系统是一项艰巨的任务，因此明智的人会重复使用他们能重复使用的任何东西（设计、库、编译器、其他软件）。很有可能它仍然需要做太多的工作，那么为什么要从头重写所有内容来让它变得更加困难呢？

事实上，它是以相反的方式完成的

我们有不同的Unix版本：两个主要系列：SystemV和BSD，不同的制造商，因此需要标准化。美国政府也希望标准化程序，所以POSIX（版本1）是通过标准化操作系统接口（比C标准更进一步）创建的

Windows NT也与POSIX（版本1）兼容，只是因为政府需要标准化的工具。所以POSIX的设计非常广泛

随着时间的推移，需要标准化更多的Unix（和类似的）系统。不仅仅是作为一个系统、一个API，而是作为通用API，因此程序（如GUI库或数据库）最终可以使用扩展，但也要确保遵循标准的程序在兼容系统上工作

这就是SUS（单一Unix规范）。这需要一个类似UNIX的系统（与POSIX 1不同）

然后POSIX变得不那么重要了：理论上可以在所有POSIX系统上运行的应用程序在POSIX Windows上并没有真正运行

因此，新版本的POSIX合并了旧的POSIX和SUS以及SUS中缺少的新的有用函数

现在Linux很重要，所以在更新POSIX时要考虑Linux实现（例如glibc）。您将在邮件列表中看到，POSIX是由不同Unix和类似系统的“供应商”定义的

因此，并不是操作系统扩展了POSIX，而是POSIX从不同的操作系统中获取了最有用和最标准的选项。它在现有接口不兼容的情况下创建新接口，通过标准化，它将破坏现有程序

---

对于“第二个”问题：当你开发一个新的操作系统时，你选择了哪种方式。通常它只是派生和fork（以及发行版）：同样来自两个Unix家族，即从RedHat或Debian派生Linuxes）。由于设计原因，有时系统是从头开始构建的。内核提供了大部分系统调用，因此，例如，glibc需要大量的系统调用（由内核提供），以与POSIX类似的方式实现。Glibc还不完整。注意：早期的Linux发行版使用了其他库。GLibc也是从零开始编写的。

看看目标平台上的C库，看看它的起源。这通常是因为版权的原因而被很好地记录下来的，而且很少（如果有的话）（出于实际原因）从零开始重写。重写没有任何好处--可用的库需要数年的测试--您不能重写并期望避免数年的时间来完全修复一个复杂的库，同时自己跟踪所有的更新和更改。因为POSIX兼容性是如此广泛的需求，我怀疑大多数C库实现者一开始就确保它们是兼容的，所以操作系统开发人员不需要做太多。虽然从技术上讲不是从头开始编写的（大多数数学或libm，C库的一部分被重新使用），但有时用现代开发工具和编译器重新开始（重要的是）是值得的。您应该调查

musl

以满足您的需求-它干净、高效，并且已经成为一些发行版和嵌入式项目的基础。我希望看到它得到完善和更广泛的采用。一个开源版本的C标准库，以及专有的将适合。