这只是一个惯例，意思是“类型”。它对编译器没有任何特殊意义。

关于这个问题有一些很好的解释。再补充一个重新定义类型的原因:

在许多嵌入式项目中，所有类型都被重新定义，以正确地声明类型的给定大小，并提高跨不同平台(即硬件类型编译器)的可移植性。

另一个原因是让你的代码可以跨不同的操作系统移植，并避免与你在代码中集成的操作系统中的现有类型发生冲突。为此，通常会添加一个惟一的(尽可能的)前缀。

例子:

typedef unsigned long dc_uint32_t;

_t通常包装不透明类型定义。

GCC只是将以_t结尾的名称添加到您可能不使用的保留名称空间中，以避免与Standard C和POSIX (GNU C库手册)的未来版本冲突。经过一番研究，我终于在POSIX标准1003.1中找到了正确的参考:B.2.12数据类型(卷:基本原理，附录:B.系统接口的基本原理，章节:B.2一般信息):

B.2.12 Data Types Defined Types The requirement that additional types defined in this section end in "_t" was prompted by the problem of name space pollution. It is difficult to define a type (where that type is not one defined by POSIX.1-2017) in one header file and use it in another without adding symbols to the name space of the program. To allow implementors to provide their own types, all conforming applications are required to avoid symbols ending in "_t", which permits the implementor to provide additional types. Because a major use of types is in the definition of structure members, which can (and in many cases must) be added to the structures defined in POSIX.1-2017, the need for additional types is compelling.

简而言之，标准说有很好的机会扩展标准类型的列表，因此标准限制了_t命名空间供自己使用。

例如，您的程序匹配POSIX 1003.1 Issue 7，并且您定义了类型foo_t。POSIX 1003.1第8版最终发布了一个新定义的类型foo_t。您的程序与新版本不匹配，这可能是一个问题。限制_t的使用可以防止代码重构。因此，如果您的目标是POSIX遵从性，那么您绝对应该避免使用标准中规定的_t。

旁注:就我个人而言，我试图坚持使用POSIX，因为我认为它为简洁的编程提供了良好的基础。此外，我非常喜欢Linux编码风格(第5章)指南。有一些很好的理由不使用typedef。希望这对你有所帮助!

例如，在C99中，/usr/include/ stdt .h:

typedef unsigned char           uint8_t;
typedef unsigned short int      uint16_t;
#ifndef __uint32_t_defined
typedef unsigned int            uint32_t;
# define __uint32_t_defined
#endif
#if __WORDSIZE == 64
typedef unsigned long int       uint64_t;
#else
__extension__
typedef unsigned long long int  uint64_t;
#endif

_t总是表示由typedef定义。

意思是类型。Size_t是大小类型。

这只是一个惯例，意思是“类型”。它对编译器没有任何特殊意义。