pathconf(..., _PC_NAME_MAX) 提供什么保证？

Question

上下文：

readdir_r 函数用于从DIR* 读取下一个条目（还有readdir，但这不是线程安全的）。 readdir_r 采用指向用户分配缓冲区的指针来保存输出 dirent。手册页指出此缓冲区所需的大小在不同系统上可能不同，并提供了如何在运行时找到安全长度的示例：

len = offsetof(struct dirent, d_name) + pathconf(dirpath, _PC_NAME_MAX) + 1;

（警告：上面有一个竞争条件，可以通过使用dirfd获取打开的DIR*的文件描述符并使用fpathconf而不是pathconf来避免）

问题：

查看pathconf 的联机帮助页，它指出：

_PC_NAME_MAX 返回允许进程创建的目录路径或 fd 中文件名的最大长度。对应的宏是_POSIX_NAME_MAX。

但是，在注释部分，它指出：

名称长度大于返回的名称等于 _PC_NAME_MAX 的值的文件可能存在于给定目录中。

这个注释是真的吗？如果是这样，readdir_r 手册页中的示例代码是否不正确？

Answer 1

对 {NAME_MAX} 的解释不符合 POSIX。 POSIX 表示，实现必须将长于 {NAME_MAX} 的名称视为错误，并且 {NAME_MAX}+1 字节的 d_name 缓冲区就足够了。

另一种选择（POSIX.1-2008）是使用scandir()，它是线程安全的，并从调用者那里抽象出这个问题。不幸的是，在任何版本的 POSIX 中都没有 scandirat() 或 fscandir()。

在许多系统上，只要对返回的struct dirent 的最后一次访问发生在对readdir() 的下一次调用之前，使用readdir() 也是安全的（这遵循关于结构体）。我认为 POSIX 没有理由不允许这样做。 readdir_r() 需要大量额外代码，这会使事情变得更慢和更复杂。