On 26/11/2025 01:55, Ted Lyngmo via Std-Proposals wrote:
> 2025-11-26 01:47, JJ Marr via Std-Proposals:
>> > As a complimentary alternative, we can address the 3rd bucket by
>> adding a yet another integer type long long long, with implementation-
>> defined width that would not be less than that of long long. For the
>> platforms where the extended precision is irrelevant (embedded
>> targets, possibly freestanding systems), the implementers can define
>> it as an alias for long long. The desktop and server targets can opt
>> for long long long to have 128 bits.

Speaking as someone who works with small embedded systems, I definitely
would not appreciate a new type that does something useful on big
systems, but is silently useless on small systems. It would be better
to say that the type is optional than that it is mandatary but might be
crippled on some systems. In the embedded world, many of us prefer to
use size-specific types to be sure our types can hold the values we need
them to hold, rather than types whose size is target dependent.

>>
>> The standard guarantees `int` is at least 16 bits, `long int` is at
>> least 32 bits, and `long long int` is at least 64 bits.
>>
>> Would there be disadvantages to breaking the symmetry that implies
>> `long long long int` would be at least 128 bits?
>
> I hope something else than `long long long` will come out of it, but no,
> introducing it wouldn't break anything unless unreasonable requirements
> were put on/around this type/typedef.
>
> Please, whatever it becomes, don't let it be `long long long`.
>

How about "very long" ? And maybe for the next type that is at least
256 bits, it could be "ridiculously long" ? :-)

More seriously, IMHO for larger types the actual bit count - or minimum
standards guaranteed bit count - has to be part of the name. This is
also a feature that should be in the intersection between C and C++, so
it makes sense for the fundamental parts to be amenable to adding to the
C standard too.

We already have a good notation that could be used here - the <stdint.h>
or <cstdint> sized integer types. So I would suggest skipping the "old
style" names entirely, and going straight to :

 int128_t
 int_fast128_t
 int_least128_t
 uint128_t
 uint_fast128_t
 uint_least128_t

The pattern for bigger sizes is obvious.

Theoretically, C++ still supports systems where integer sizes are not
powers of two. (It certainly still supports systems that might have
16-bit or 32-bit char.) In practice, I have difficulty imagining any
future system supporting integer types that are at least 128 bits, but
not supporting integer types of exactly 128 bits. Still,
"int_fast128_t" seems to me to be a clear alternative to "long long long".

There are a few details that would need to be tied up to allow this.
One is the "intmax_t" issue - it is very difficult to change the size of
"intmax_t" as it is a low-level ABI breaker and could have a significant
impact on the working and efficiency of existing code. C23, when it
added _BitInt types, allowed integer types that are bigger than
"intmax_t". Bigger extended integer types are also allowed, as long as
they are referred to by exact-width names ("int128_t"). I am sure this
could be tweaked again to allow "int_least128_t", and copied over to C++.


David