据我了解， intptr_t 的定义因架构而异——它保证能够表示一个指针，该指针可以访问进程的所有统一地址空间。
Nginx（流行的开源网络服务器）定义了一个用作标志（布尔值）的类型，这是一个 typedef 到intptr_t. 现在以 x86-64 架构为例——它可以访问涵盖所有大小操作数的大量指令——为什么将标志定义为 intptr_t ？当然，使用 32 位 bool 类型的传统也符合要求吗？
我已经了解了 32 位 Vs。当我还是一名新开发人员时，我自己争论 8 位布尔值，结论是由于处理器设计的复杂性，32 位布尔值在常见情况下表现更好。那么为什么需要转移到 64 位 bools 呢？
唯一真正知道为什么 nginx 使用intptr_t布尔类型的人是 nginx 开发人员。
正如您所说，对于常见情况，32 位布尔值通常比 8 位布尔值表现得更好。我自己没有做过基准测试，但在 x86-64 上的某些情况下，64 位布尔值优于 32 位布尔值对我来说并非不合理。例如，在 nginx 源代码中，我注意到大多数 ngnx_flag_t' 出现在具有其他(u)intptr_ttypedef 类型的结构中。由于对齐填充，32 位布尔可能不会在此处节省空间。
我确实觉得这个选择intptr_t有点奇怪，因为它是一个可选的 C99 类型，目的是转换为/从void *. 但据我所知，它从来没有被这样使用过。也许这种类型给出了“本机”字大小类型的最佳近似值？
64bit bool 对于 x86-64 来说听起来是个糟糕的主意。我猜写它的人当时正在考虑使用 32 位指针的 32 位机器。
现代 x86 对未对齐的加载/存储以及解包字节以动态填充寄存器有很好的支持。如果 x86 是主要目标，则应首选 8 位布尔值，尤其是在它节省字节从而减少缓存使用的情况下。在缓存根本不是问题的极少数情况下，32 位是自然大小，并且在某些情况下int，通过允许布尔值用作内存操作数，可能会在布尔值直接与 相加或相乘的情况下保存指令，而不是加载一个movzx.
对于布尔值上的 test&branch 的通常情况，英特尔和 AMD CPU 在 8 位和 32 位操作数之间的性能差异实际上为零，无论是在内存中还是在寄存器中。