> Plenty of software works fine with different CHAR_BIT values, although some poorly-written programs do need to be fixed.
Since C traditionally doesn’t have much of a testing culture I’m not sure you can trust any decent sized project here. I’d even be surprised if you could change the size of ‘int’. And moving off 2s complement is definitely out.
`long` is such a mess in C I never use it anymore. I use `int` and `long long`. `long` is so useless today that it's a code smell and the Standard should just delete it.
Both Linux (in C) and Rust choose to name types based on the physical size so as to be unambiguous where possible, although they don't entirely agree on the resulting names
Linux and Rust agree u32 is the right name for a 32-bit unsigned integer type and u64 is the name for the 64-bit unsigned integer type, but Rust calls the signed 32-bit integer i32 while Linux names that s32 for example.
It would of course be very difficult for C itself to declare that they're now naming the 32-bit unsigned integer u32 - due to compatibility. But Rust would actually be able to adopt the Linux names (if it wanted to) without issue, because of the Edition system, simply say OK in the 2023 edition, we're aliasing i32 as s32, and it's done. All your old code still works, and raw identifiers even let any maniacs who named something important "s32" still access that from modern "Rust 2023" code.
I didn't choose the integer suffixes for types because:
1. they are slower to type
2. they just aren't pretty to look at
3. saying and hearing `int` is so much easier than `eye thirty-two`. Just imagine relying on a screen reader and listening to all those eye thirty two's
4. 5 minutes with the language, and you know what size `int` is, as there is no ambiguity. I haven't run across anyone confused by it in 20 years :-)
If I was designing a new language I'd rather specify integer types by their range of expected values, and let the storage size be an implementation detail.
(not sure if this would ever come up, but if a variable had eg values 1000-1003, then technically you could optimize it to a 4-bit value.)
Depending on what your language is for you probably want both.
WUFFS type base.u8[0 ..= 42] is a type which fits in one byte but only has values zero through 42 inclusive, and it's a different type from base.u32[0 ..= 42] because that one takes four bytes.
Rust cares about this stuff to some extent but only internally, for types with a "niche" where it can squirrel away the None case of Option in an invalid value without needing more space. e.g. Rust's optional pointer is the same size as a traditional C-style pointer, because NULL isn't a valid pointer value so that means None, and Rust's optional NonZeroU64 is the same size as a u64 (64-bits) because zero isn't valid so that means None.
Don't. Every type has its place in a well-defined structure, passing through main architecture changes.
Use 'int' if the expected range of values fit in 16 bits, use 'long' if it fits in 32 bits and use 'long long' otherwise. 'int' is guaranteed to be the fastest at-least-16 bit type and 'long' is guaranteed to be the fastest at-least-32 bit type for any architecture (matching the register width on most 32/64 bit platforms - except Windows, and being 32-bit wide even on 8/16 bit architectures), and each of these types have their own promotion class.
Don't use fixed width types by default as printing them or converting to string correctly will get ugly: printf("... %" PRId32 " ...");
Generally avoid the use of fixed-width 8-bit or 16-bit types in calculations or you might shoot yourself in the foot due to integer promotion rules.
Use fixed width types only for things that pass the boundary of a system, like in HW registers, serializing, database storage or network packets, but cast only at the end when converting to the type (optionally followed by bitwise manipulations) and cast immediately to other type when processing (after bitfield extraction and such things, of course).
Since C traditionally doesn’t have much of a testing culture I’m not sure you can trust any decent sized project here. I’d even be surprised if you could change the size of ‘int’. And moving off 2s complement is definitely out.