2

这个问题涉及需要在 POSIX/SUS 标准的所需标头中定义的各种类型。

某些类型需要在许多头文件中定义,我想知道实现这一点的正确且合规的方法是什么。

例如,查看<time.h>标头规范:

包含标头可能会使 <signal.h> 标头中的所有符号可见。

这很简单,<signal.h>包含在<time.h>.

现在怎么样:

clock_tsize_ttime_tclockid_ttimer_t类型应按照 <sys/types.h> 中的描述进行定义。

据我了解,这意味着我们不能简单地包含<sys/types.h>from <time.h>,因为这会暴露比所需更多的符号。

那么任何人都可以证实这一点吗?
包括在内会违反标准合规性<sys/types.h>吗?

如果是这样,我认为最好的解决方案是为每种类型创建一个特定的标头,以便可以从任何地方使特定类型可见,而不必担心其他符号。
有没有其他好的解决方案?

最后一件事,C 标准中的类型呢?
POSIX/SUS 规范中的许多类型都是整数类型,可能需要具有固定宽度。

那么标准是否可以<stdint.h>从特定标题中包含,还是会破坏合规性?

4

2 回答 2

1

你是对的,从额外的头文件中暴露不需要的类型和声明是不符合标准的。

一个微不足道的(但是,就预处理器打开文件所花费的时间而言,代价高昂)的解决方案是为每种类型设置一个单独的标头,并且在您需要时,例如time_t,执行以下操作:

#include <types/time_t.h>

当然types/time_t.h会有适当的多重包含警卫。

还有许多其他方法可以实现相同的目标。glibc 和 gcc 使用的方法是在包含一个要求它只提供一种或多种类型的标题之前定义特殊的“需要”宏。这个解决方案也非常昂贵,可能比上面的更昂贵,因为它打破了编译器对多重包含保护的启发式方法。编译器不能省略重复的包含;每次包含该文件时,它都必须对其进行解析。

我们在 musl 中执行此操作的方式是拥有一个文件,bits/alltypes.h其中包含多个头文件和宏控制所公开的所有类型所需的定义。它是由一个隐藏所有宏逻辑的简单 sed 脚本生成的:

于 2013-07-31T17:30:14.110 回答
0

在阅读了这个问题后,我忍不住在有史以来最大的 UNIX 兼容(严格来说,只有“类 UNIX”)开源项目 - Linux Kernel(它几乎总是担心标准合规性)中对此进行了检查如今)。


示例实现:

time.h头将定义一些内部标志,然后包含types.h定义所有类型的,尽管在#ifdefs 中检查是否定义了某些内部标志。

所以这归结为以下几点:

  1. 定义模块化标题,如time.h
  2. #define相关的内部标志来建立上下文。
  3. 包括提供依赖关系的“内部”标头。
  4. 实现“内部”标头,以便它们根据它们被编辑的上下文选择性地公开功能#include

通过这种方式,可以提供模块化头文件以供包含,而不必担心意外暴露比所需更多的符号。

于 2013-07-31T16:52:31.887 回答