On 26/11/2025 01:57, Lev Minkovsky via Std-Proposals wrote:
> If we are to force implementers to have *long long long* as at least 128
> bit, we will risk the embedded community to simply reject/not implement
> this proposal as too burdensome and irrelevant. I am hoping for this to
> be sufficiently lightweight to be as universally accepted as *long long.
>

As an embedded programmer, I strongly reject that idea. I'd rather not
have "long long long" at all, than have it sometimes be no bigger than
"long long". And the type itself will be useless to me unless it comes
with standard aliases with the bit size given explicitly. "int128_t" is
my preference, but I'd much rather have "integer_type_128_bits" or
"std::int_t<128>" than "long long long".

C23 introduced _BitInt's with arbitrary bit lengths, and there are
proposals for adding them to C++. C23 only requires _BitInt to support
up to a length of the bit size of "long long int", but compiler
developers are already supporting bigger sizes. For embedded compilers
that attempt to fully support modern C and C++ standards, there are
really only two toolchains - gcc and clang. Clang already supports
_BitInt of huge size on all targets, while gcc currently only has them
on 64-bit targets but is working on support for smaller devices. So I
think any compiler that is going to support C++29 will be able to add
something like "typedef _BitInt(128) long long long int;".

There are some other major embedded compiler developers left in the
market that are still trying to have at least reasonable support for
newer standards. It is not at all unreasonable to suppose they would
find it simpler to implement a 128-bit integer than full _BitInt
support. (It is also entirely reasonable to suppose that specific
128-bit integers might be supported more efficiently than arbitrary
sized _BitInt types.) But I really do not expect 128-bit types to be a
larger burden - these compilers already deal with integer types bigger
than the target's GPR's and ALUs.

But having "long long long" mean significantly different things on
different platforms would be a massive burden on embedded /programmers/
- and that counts far more than the burden on implementers. It would be
far better if those embedded compiler developers that thought 128-bit
integers are too burdensome to implement simply do not implement "long
long long".

> *Also, if we are to move forward with further consideration, we will
> need to decide if the variant *long long long int *makes sense. Perhaps
> simply *long long long* (without the int) would be sufficient, although
> that would be another symmetry breakage.
>

I personally have never liked using "long" or "short" as type names.
The words are adjectives - a long /what/ ? Usually I use size-specific
types, or typedef's, but if I want the type "long long int", that's what
I write. So I would see being allowed to write "long long long" as an
obvious continuation of the existing pattern for those that prefer that
style, but disallowing "long long long int" would be a bad idea.

David