Could you explain, when the promotion would be detrimental?

E.g.: unsigned overflow is defined behaviour (in comparison to signed overflow), but would it be useful, when you cannot predict the bitwidth?

-----Ursprüngliche Nachricht-----
Von: Frederick Virchanza Gotham via Std-Proposals <>
Gesendet: Fr 31.03.2023 13:47
Betreff: [std-proposals] uint_nopro_fast32_t : Types in <cstdint> that don‘t promote
An: std-proposals <>;
CC: Frederick Virchanza Gotham <>;
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:



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;
Std-Proposals mailing list