什么是“命名空间清洁度"，glibc如何实现? [英] What is "namespace cleanliness", and how does glibc achieve it?

问题描述

我最近从 @zwol的答案中发现了这一段:

read上的__libc_前缀是因为在C库中，实际上read有三个不同的名称:read，__read和__libc_read.这是一种实现命名空间整洁"的技巧，如果您打算实施完全成熟且完全符合标准的C库，则只需担心.简短的版本是C库中有许多需要调用read的函数，但是其中一些不能使用 name read来调用它，因为技术上允许使用C程序定义一个名为read的函数本身.

你们中有些人可能知道，我开始实施我自己的成熟且完全标准的-兼容的C库，因此我想了解更多详细信息.

什么是命名空间清洁度"，glibc如何实现?

解决方案

首先，请注意，标识符C1完全不被ISO C保留.严格符合ISO C的程序可以具有称为read的外部变量或函数.但是，POSIX具有称为read的功能.那么，我们如何拥有一个带有read的POSIX平台，同时允许C程序呢?毕竟fread和fgets可能使用read;他们不会休息吗?

一种方法是将所有POSIX内容拆分到单独的库中:用户必须链接-lio或任何内容以获取read和write及其他功能(然后具有fread和getc使用一些替代的读取功能，因此即使没有-lio也可以使用.

glibc中的方法不是使用像read这样的符号，而是使用保留名称空间中的像__libc_read这样的替代名称来避免出现这种情况.通过将read用作__libc_read的弱别名，可以将read用于POSIX程序.对read进行外部引用但未定义的程序将到达弱符号read，该符号别名为__libc_read.定义read的程序将覆盖弱符号，而它们对read的引用将全部移至该覆盖.

重要的是，这对__libc_read没有影响.此外，它需要使用read函数的库本身会调用其内部不受程序影响的__libc_read名称.

因此，所有这些加在一起就是一种清洁度.这不是在具有许多组件的情况下可行的名称空间整洁的通用形式，但是它在两方情况下起作用，其中我们唯一的要求是将系统库"和用户应用程序"分开.

I came across this paragraph from this answer by @zwol recently:

The __libc_ prefix on read is because there are actually three different names for read in the C library: read, __read, and __libc_read. This is a hack to achieve "namespace cleanliness", which you only need to worry about if you ever set out to implement a full-fledged and fully standards compliant C library. The short version is that there are many functions in the C library that need to call read, but some of them cannot use the name read to call it, because a C program is technically allowed to define a function named read itself.

As some of you may know, I am setting out to implement my own full-fledged and fully standards-compliant C library, so I'd like more details on this.

What is "namespace cleanliness", and how does glibc achieve it?

解决方案

First, note that the identifier read is not reserved by ISO C at all. A strictly conforming ISO C program can have an external variable or function called read. Yet, POSIX has a function called read. So how can we have a POSIX platform with read that at the same time allows the C program? After all fread and fgets probably use read; won't they break?

One way would be to split all the POSIX stuff into separate libraries: the user has to link -lio or whatever to get read and write and other functions (and then have fread and getc use some alternative read function, so they work even without -lio).

The approach in glibc is not to use symbols like read, but instead stay out of the way by using alternative names like __libc_read in a reserved namespace. The availability of read to POSIX programs is achieved by making read a weak alias for __libc_read. Programs which make an external reference to read, but do not define it, will reach the weak symbol read which aliases to __libc_read. Programs which define read will override the weak symbol, and their references to read will all go to that override.

The important part is that this has no effect on __libc_read. Moreover, the library itself, where it needs to use the read function, calls its internal __libc_read name that is unaffected by the program.

So all of this adds up to a kind of cleanliness. It's not a general form of namespace cleanliness feasible in a situation with many components, but it works in a two-party situation where our only requirement is to separate "the system library" and "the user application".

这篇关于什么是“命名空间清洁度"，glibc如何实现?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！