答案 0 :(得分：5)
不，不是。无论如何，我建议不要使用[u]int_fastN_t类型。在现实世界的系统中，它们被错误定义;例如，uint_fast32_t通常在x86_64上被定义为64位类型，尽管64位操作最多（加法，减法，逻辑运算）与32位运算速度相同，最差多较慢（除法和加载/存储，因为你使用了两倍的缓存行）。
答案 1 :(得分：2)
C标准只要求int至少为16位且宽度没有上限，因此uint_fast32_t可能比int窄，或宽度相同，或者宽。
例如，符合标准的实现可以使int 64位和uint_fast32_t为32位unsigned short的typedef。或者，相反，int可以是16位，uint_fast32_t，顾名思义，必须至少为32位。
一个有趣的结果是：
uint_fast32_t x = UINT_FAST32_MAX;
uint_fast32_t y = UINT_FAST32_MAX;
x * y;
可能会溢出，导致未定义的行为。例如，如果short为32位且int为64位，则uint_fast32_t可以是unsigned short的typedef，这将促进签名在乘之前的int;结果近2 64 ，太大而不能表示为int。
POSIX要求int和unsigned int至少为32位，但即使对于POSIX兼容的实现，您的问题的答案也不会改变。 uint_fast32_t和int仍可分别为32位和64位，或64位和32位。 （后者意味着64位类型比int更快，这是奇怪的，因为int应该具有建筑物＃34;建议的＆＃34;自然大小，但是它是允许的。）
实际上，大多数编译器实现者倾向于尝试使用预定义类型覆盖8,16,32和64位整数，这可能只有int不超过32位。我见过的唯一没有遵循这个的编译器是Cray矢量机器。 （扩展的整数类型可以解决这个问题，但我还没有看到编译器利用它。）
如果没有，是否有任何其他无符号类型保证在 至少32位且至少与
int一样大？
是，unsigned long（和unsigned long long至少为64位。）