我从以下地方看到这一段@zwol 的回答 https://stackoverflow.com/a/57728805/10795151最近：
The __libc_前缀于read是因为实际上有三个不同的名称read在 C 库中：read, __read, and __libc_read。这是一个实现“命名空间清洁度”的 hack，只有当您打算实现一个成熟且完全符合标准的 C 库时，您才需要担心这一点。简而言之，C 库中有很多函数需要调用read，但其中一些不能使用name read调用它，因为从技术上讲，C 程序允许定义一个名为read itself.
你们中有些人可能知道，我是着手实现我自己的成熟且完全符合标准的 C 库 https://github.com/JL2210/minilibc.git，所以我想了解更多详细信息。
什么是“命名空间清洁度”，glibc 是如何实现的？
首先，注意标识符readISO C 根本不保留。严格符合 ISO C 程序可以有一个名为的外部变量或函数read。然而，POSIX 有一个函数叫做read。那么我们怎样才能拥有一个 POSIX 平台read那同时允许C程序吗？毕竟fread and fgets可能会使用read;它们不会破裂吗？
一种方法是将所有 POSIX 内容分成单独的库：用户必须链接-lio或任何能得到的东西read and write和其他功能（然后有fread and getc使用一些替代的读取功能，因此即使没有，它们也可以工作-lio).
glibc 中的方法是不使用类似的符号read，而是通过使用替代名称来避免妨碍，例如__libc_read在保留的命名空间中。的可用性readPOSIX 程序是通过以下方式实现的read a 弱别名 for __libc_read。进行外部引用的程序read，但不定义它，将到达弱符号read哪些别名__libc_read。定义的程序read将覆盖弱符号，以及它们对read都会去那个覆盖。
重要的是这对__libc_read。此外，图书馆本身，it需要使用read函数，调用其内部__libc_read不受程序影响的名称。
所以所有这些加起来就是一种清洁。它不是在具有许多组件的情况下可行的命名空间清洁的一般形式，但它在两方情况下工作，我们唯一的要求是将“系统库”和“用户应用程序”分开。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
