Why isn't the existence of all minimum-width integer types (up to 64 bits) required?

Question

In both C99 and C11 (at least their final drafts), we find that the existence of uint_least8_t, uint_least16_t, uint_least32_t, uint_least64_t in <stdint.h> is required, along with their signed variants.

I'd think that a requirement of the availability of uint_least{N}_t for all N between 1 and 64 would be reasonable. Is there a good reason why this isn't the case? If implementations must supply 8, 16, 32, and 64, then surely an implementation for all smaller values of N should be feasible (e.g. typedef uint_least16_t uint_least15_t; etc. would be obvious for x86).

I'm asking because I found myself wanting a uint_least21_t type to store a single Unicode codepoint, which can have any value between U+0000 and U+10FFFF inclusive (a constraint introduced in Unicode 4.0). I'd think this would be a more accurate choice, in case some target architecture happens to have (for instance) fast 24-bit integers. Right now, I'm stuck with a big preprocessor section, where I'm testing defined(UINT_LEAST{N}_MAX) with N between 21 and 32 to pick the right type.

Answer 1

Most modern hardware (and compilers) current since 1999 can reasonably implement 8,16,32, and 64 bit unsigned types. In fact, on a fair few modern implementations, unsigned char, unsigned short, unsigned long, and unsigned long long ARE implemented as 8,16,32, and 64 bit unsigned types - although, strictly strictly speaking, that is permitted but not required.

That means, for compiler vendors, uint_least8_t, uint_least16_t, uint_least32_t, uint_least64_t can be easily supported. Compiler vendors would not put up strong resistance.

That is not the case for other such types. For example, there are very few instances of hardware that natively supports an unsigned integral type of the form uint_leastN_t for other values of N. Which means the compiler (or library) would need to emulate those types (probably in terms of native types that the hardware does support).

Furthermore, relatively few programmers, in practice, have a burning need for (say) a uint_least21_t, and even fewer are willing to lay down cold hard cash to buy a compiler and library that does.

So there is a combination of circumstances. Compiler or library vendors (who have a vote in committee proceedings) would be less than enthused at emulating such types unless there is profit in it (i.e. a lot of paying customers offering to pay good money for a compiler or library with such features). Furthermore, there would be relatively few programmers with the interest in using such a feature with enough commercial or political clout to convince a vendor it is worth the cost (man hours, etc) of developing their compilers and libraries to support such types.

The path of least resistance, for the standardisation committee, would be to only make a few of the types mandatory. After all, there are more important features to vote into the standard than facilities which few programmers need, even fewer are willing to pay for, and that relatively few vendors would bother to implement.