> Yes, the u{...}int names are important. Those "different names" are
> normally for other (though obviously related) purposes (conceptually
> int_exact_*), and the int_least_* and int_fast_* names, usually are built

the int_least_* names appear to me to be completely wasted, given
this is how the normal types are defined and that you couldn't depend
on the extra bits.

Kind of. The thing is there is the minimums required by the standard and then there is the minimums provided by the implementation, the latter of which at least has to match the former. But yes, the least names can be viewed to just thrown a wrench into it all.

also, how do you debug code written like this?

Not easily especially when you begin to look at its interaction with I/O as well.

one complete test for each possible definition of int_least_*?
of course, that leads to the question, is that set known?

one also wonders about int_fast_* as well. fast /for what/ exactly?

IIRC the Standard even specifically leaves that question open. I think the goal was to try to codify/match some existing practice at the time realizing that it wasn't perfect but at least gave a fight chance in some situation and in those it couldn't, there was probably going to be bumps in the road either way. I know it can lead to a why bother situation then.

it seems that all this is in respose to the fact that the c-std version
of u32int is not required.

IIRC the full set is not required but I think say uint32_t is. But it's been so long you might just be right.

(the names are somewhat offensive to
good taste, so i refer to them as one does carlin's list, by suggestion.)
rather than fix that issue, layering on another set of types was the
solution. really?

IIRC the naming was raised a number of times.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm :

“ It can also be argued that programmers that use the 'intN_t' more than
likely really meant to use the 'int_leastN_t' types. Such programmers
probably want a type with a guaranteed number of bits rather than an
exact number of bits.

It can be argued further that use of the 'intN_t' names is not portable
because they may not exist in all implementations. (An implementation
is not required to provide these types.)

unfortunately, there are still programmers who use the definition
more complicated ≡ more better. evidently believing in the
transitive nature of "more" over false premises.

Personally I could never buy the whole argument for all those names and such, and probably would be happy with just the exact ones. I'm trying to recall the exact etymology of it but it's too long ago to recall.