I write code for desktop PC's with a 64-Bit x86 CPU, as well as
embedded Linux devices with 32-Bit and 64-Bit ARM processors (arm +
aarch64), as well as Atmel microcontrollers (thumb) and also Texas
Instruments microcontrollers.

When I write a new library, I try to keep these 5 different
architectures in mind, especially the last one which has a 16-Bit byte
(i.e. 16 == CHAR_BIT). Also I keep in mind that in future I might
compile for a system that has a 64-Bit int.

Sometimes I shy away from the integer types in <cstdint>, for example
sometimes I use 'long unsigned' instead of 'uint_fast32_t', because
the latter might promote to a signed integer.

So I wonder would it be good to have another set of integer types that
don't promote? For example:

    uint_nopro_least8_t
    uint_nopro_least16_t
    uint_nopro_least32_t
    uint_nopro_least64_t

    uint_nopro_fast8_t
    uint_nopro_fast16_t
    uint_nopro_fast32_t
    uint_nopro_fast64_t

On a machine that has a 64-Bit int, the eight types listed above would
all be typdef's for uint64_t. On a machine that has a 32-Bit int,
you'd have:

    typedef uint32_t uint_nopro_least8_t;
    typedef uint32_t uint_nopro_least16_t;
    typedef uint32_t uint_nopro_least32_t;
    typedef uint64_t uint_nopro_least64_t;

    typedef uint32_t uint_nopro_fast8_t;
    typedef uint32_t uint_nopro_fast16_t;
    typedef uint32_t uint_nopro_fast32_t;
    typedef uint64_t uint_nopro_fast64_t;