epoll_data_t 问题（特别是关于 C 数据类型）答案

【问题标题】：epoll_data_t question (specifically about C data types)epoll_data_t 问题（特别是关于 C 数据类型）
【发布时间】：2010-01-03 20:55:54
【问题描述】：

联合 epoll_data_t 看起来像：

typedef union epoll_data {  
    void *ptr;  
    int fd;  
    __uint32_t u32;  
    __uint64_t u64;  
} epoll_data_t;

这更像是一个通用的 C 问题，但为什么使用前导双下划线 __uint{32,64} 类型而不是仅使用不带下划线的 uint{32,64} 类型？我真的不明白为什么/何时使用下划线版本，但我认为没有下划线的 uint32 将是在可公开修改的联合中使用的正确方法。

【问题讨论】：

标签： c typing epoll

【解决方案1】：

C99 对定宽整数类型进行了标准化。在此之前，编译器和库的作者介绍了他们自己的类型，其中这些可能是残余的； afaik MS 仍然没有与 Visul Studio 一起发布 stdint.h。

【讨论】：

【解决方案2】：

直接来自维基百科 [http://en.wikipedia.org/wiki/Underscore]

许多冲突是可能的外部标识符链接空间这可能会混合代码由各种高层产生需要编译器、运行时库通过这些编译器中的每一个，编译器生成的辅助函数，以及程序启动代码，其中一些分数不可避免地从系统汇编语言。这里面碰撞域下划线性格很快变得根深蒂固的主要机制区分外部链接空间。这是 C 的常见做法编译器添加前导强调所有外部范围避免冲突的程序标识符来自运行时的贡献语言支持。此外，当需要引入的C/C++编译器名称作为外部链接的一部分翻译过程，这些名字经常被区分为一些多个前导的组合或尾随下划线。

【讨论】：

这实际上与这个特定问题无关 - 它与类型名称有关，在 C 中没有链接。

【解决方案3】：

前导下划线保留给编译器/库供应商，以避免在全局命名空间中创建与客户创建的符号冲突的符号。不幸的是，客户也一直在将其用于他们自己的“系统级”声明，就像 3rd 方库供应商一样，迫使供应商开始使用两个下划线。带有 3 个下划线的符号已在野外被发现，但尚未广泛传播。

【讨论】：