stdint.h在开发这些库时并不存在。所以每个图书馆都制作了自己typedef的s。
对于较旧的库，这是必需的，因为有问题的标头 ( stdint.h) 不存在。
但是，仍然存在一个问题：这些类型（uint64_t和其他类型）是标准中的可选功能。因此，合规的实现可能不会随它们一起提供——因此现在迫使库仍然包含它们。
stdint.h自 1999 年以来已被标准化。更可能的是，许多应用程序定义（实际上是别名）类型以保持与底层机器架构的部分独立性。
它们使开发人员确信在他们的应用程序中使用的类型与他们的项目特定的行为假设相匹配，而这些假设可能与语言标准或编译器实现都不匹配。
这种做法反映在面向对象的外观设计模式中，并且被开发人员滥用，他们总是为所有导入的库编写包装类。
当编译器不那么标准并且机器架构可能从 16 位、18 位到36 位字长的大型机变化时，这需要更多的考虑。现在，在融合 32 位 ARM 嵌入式系统的世界中，这种做法的相关性要小得多。对于具有奇数内存映射的低端微控制器来说，这仍然是一个问题。
所以你有能力将 char 类型转换为 int。
一个“编码恐怖”提到，一个公司的标题有一个程序员想要一个布尔值的地方，而 char 是该工作的逻辑本机类型，所以写了typedef bool char. 后来有人发现整数是最合乎逻辑的选择，并写了typedef bool int. 结果，在 Unicode 之前的年代，实际上是typedef char int.
我认为相当多的前瞻性，向前兼容性。