That, presumably, would be why your applicaqtion specific integer types would often boil down to unsigned char or signed char.
That's why int exists. It's minimum size requirements cause an issue with 8-bit micros in that regard, but otherwise it will be the native integer type (and thus the most efficent). Any non 8bit platform for which that's not true? In particular any 16 bit platform that uses a 32 bit int? It's forbidden by what I uderstand to be the spirit of the language.
The int(size) definitions, however, select a type w/o regard for its efficiency.
The fast and at least types do provide some advantages here, but I don't think I've ever seen them 'in the wild'.
The int(size) macro are butt barnacles on the language to coin a phrase.
In any case none of the stdint type should IMO be used directly, but rather as the basis of application specific types where appropriate. The application specific types then give you additional type checking (beyond size).
At that point you are so specific that using the appropriate underlying type is no more difficult. There is a minor documentation advantage but that's it. On a number of interfaces even that is misleading. There are inferfaces where a 32 bit number must be broken into parts for writing and others where an 8 bit number must be written as a 32 bit so the size of the I/O and the size of the value written (or read) may be somewhat independant.
But size only covers a small portion of that issue. You also have to deal with endianess and alignment at least. Size is actually the least troublesome IME.
Well if you are doing logic it's one bit by definition ;)
Bitwise operations are another question but width is only an issue when going to the hardware. Theres some modulo arithmetic that's used for checksums etc but that's a small portion of the code I've dealt with. Modulo arthmetic on buffers is best done in other ways.
Now a standard way to introduce MAC operations and saturating arithmetic might be interesting but I doubt there's enough experience with them to justify burden the language with them.
This one rather left me open mouthed with astonishment.
Robert