_t（下划线-t）代表什么types？
这似乎是一个简单的问题，但我无法find堆栈溢出search或谷歌。 一个types后跟一个_t是什么意思？ 如
int_t anInt;
我在C代码中看到了很多与硬件密切相关的东西 – 我不禁想到它们是相关的。
正如Douglas Mayle指出的那样，它基本上表示一个types名称。 因此，如果用' _t '来结束variables名或函数名，你可能会觉得不舒服。 和size_t ，C89标准定义了wchar_t ， off_t ， ptrdiff_t ，也许还有一些我忘记了的东西。 C99标准定义了许多额外的types，如uintptr_t ， intmax_t ， int8_t ， uint_least16_t ， uint_fast32_t等等。 这些新types在<stdint.h>中正式定义，但是大多数情况下，您将使用<inttypes.h> （对于标准C头文件而言，通常使用）包含<stdint.h> 。 它（ <inttypes.h> ）也定义了用于printf()和scanf()macros。
正如Matt Curtis所说，后缀中的编译器没有任何意义。 这是一个以人为本的公约。
不过，你也应该注意到，POSIX定义了很多以' _t '结尾的额外types名称，并保留了实现的后缀。 这意味着如果你正在使用POSIX相关的系统，那么使用这个约定来定义你自己的types名是不明智的。 我工作的系统已经完成了（超过20年）。 我们经常被定义与我们定义的名字相同的types的系统绊倒。
这是一个用于命名数据types的约定，例如typedef ：
typedef struct { char* model; int year; ... } car_t;typedef struct { char* model; int year; ... } car_t;
_t通常包装一个不透明的types定义。
GCC仅添加以_t结尾的名称到您可能不使用的保留名称空间，以避免与未来版本的标准C和POSIX （GNU C库手册）冲突。 经过一番研究，我终于在POSIX标准（1003.1，理由（资料性附录））中find了正确的参考：
B.2.12数据types
本部分定义的其他types以“_t”结尾的要求是由于名称空间污染的问题。 在一个头文件中定义一个types（其types不是IEEE Std 1003.1-2001定义的types）是很困难的，并且在另一个头文件中使用它，而不会在程序的名称空间中添加符号。 为了允许执行者提供他们自己的types，所有符合的应用程序都需要避免以'_t'结尾的符号，这允许执行者提供额外的types。 由于types的主要用途是在结构成员的定义中，可以（并且在许多情况下必须）将其添加到IEEE Std 1003.1-2001中定义的结构中，所以对额外types的需要是令人信服的。
简而言之，标准说扩展标准types列表的机会很大，因此标准限制了_t命名空间的使用。
例如，您的程序与POSIX 1003.1问题6匹配，并且您定义了一个typesfoo_t 。 POSIX 1003.1问题7最终以新定义的typesfoo_t 。 您的程序与新版本不匹配，这可能是一个问题。 限制_t使用可以防止重构代码。 因此，如果你的目标是符合POSIX标准，你应该避免像标准所述的那样。
附注：个人而言，我试图坚持POSIX，因为我认为它为清洁编程提供了良好的基础。 而且，我非常喜欢Linux编码风格（第5章）指南。 为什么不使用typedef有一些很好的理由。 希望这个帮助！
这是数据types的标准命名约定，通常由typedef定义。 处理硬件寄存器的很多C代码使用C99定义的标准名称来表示有符号和无符号的固定大小的数据types。 作为惯例，这些名称是在一个标准的头文件（stdint.h）中，并以_t结尾。
这意味着types。 size_t是大小types。
_t本身没有任何特殊的含义。 但是已经普遍使用将_t后缀添加到typedef中。
您可能更熟悉variables命名的常见C实践…这与在前面为指针粘贴ap以及在全局variables前面使用下划线（这不太常见）相似， ，并将variables名称i ， j和k用于临时循环variables。
在字符大小和sorting很重要的代码中，使用自定义的明确types（例如BYTE WORD （通常是16位） DWORD （32位））非常常见。
int_t不是很好，因为int的定义在不同平台之间有所不同 – 那么你的int是否符合？ （尽pipe现在大多数以PC为中心的开发将其视为32位，但非PC开发的许多东西仍将int视为16位）。
这只是一个意思是“types”的惯例。 这对编译器没什么特别的意义。
如果您正在处理硬件接口代码，那么您正在查看的代码的作者可能已经将int_t定义为特定的大小整数。 C标准没有为inttypes指定一个特定的大小（这可能取决于你的编译器和目标平台），使用特定的int_ttypes可以避免这种可移植性问题。
这是硬件接口代码的一个特别重要的考虑因素，这可能就是为什么你首先注意到那里的惯例。
关于这个问题有几个很好的解释。 只是为了重新定义types添加另一个原因：
在许多embedded式项目中，所有types都被重新定义，以正确说明给定的types大小，并提高跨不同平台（即硬件types编译器）的可移植性。
另一个原因是将代码移植到不同的操作系统中，并避免与您在代码中集成的操作系统中现有types的冲突。 为此，通常添加一个独特的（尽可能）前缀。
例：
typedef unsigned long dc_uint32_t;
