在C99和C11（至少是他们的最终草稿）中，我们发现{{1}中存在uint_least8_t，uint_least16_t，uint_least32_t，uint_least64_t是必需的，以及他们签名的变体。
我认为要求所有 N 的<stdint.h>在1到64之间的可用性是合理的。是不是有充分理由不是这样的？如果实现必须提供8,16,32和64，那么对于所有较小的 N 值的实现肯定是可行的（例如uint_least{N}_t等对于x86来说是显而易见的。 / p>
我问，因为我发现自己想要一个typedef uint_least16_t uint_least15_t;类型来存储单个Unicode代码点，该代码点可以包含uint_least21_t和U+0000之间的任何值（Unicode中引入的约束） 4.0）。我认为这将是一个更准确的选择，以防一些目标架构碰巧（例如）快速24位整数。现在，我遇到了一个很大的预处理器部分，我在21到32之间使用 N 测试U+10FFFF以选择正确的类型。
答案 0 :(得分：1)
自1999年以来，大多数现代硬件（和编译器）可以合理地实现8,16,32和64位无符号类型。实际上，在一些现代实现中，unsigned char，unsigned short，unsigned long和unsigned long long实现为8,16,32和64位无符号类型 - 尽管严格来说，这是允许但不是必需的。
这意味着，对于编译器供应商，可以轻松支持uint_least8_t，uint_least16_t，uint_least32_t，uint_least64_t。编译器供应商不会提出强烈阻力。
其他类型的情况并非如此。例如，很少有硬件实例支持其他N值的uint_least N _t格式的无符号整数类型。这意味着编译器（或库）需要模拟那些类型（可能是硬件支持的本机类型）。
此外，在实践中，相对较少的程序员急需（例如）uint_least21_t，甚至更少的人愿意用冷硬现金购买编译器和库。
所以有各种情况。编辑或图书馆供应商（在委员会程序中投票）除了有利润之外（即很多付费客户愿意为具有此类功能的编译器或库提供支付），对于模仿此类类型并不乐观。此外，相对较少的程序员有兴趣使用这样的功能，具有足够的商业或政治影响力，以说服供应商开发他们的编译器和库以支持这些类型的成本（工时等）。
对于标准化委员会来说，阻力最小的路径只是强制要求一些类型。毕竟，投票进入标准的重要特征比少数程序员需要的设施更多，更少的人愿意支付，并且相对较少的供应商会费心去实施。