On Wed, 29 Mar 2023 at 10:16, Timur Doumler <cpp@timur.audio> wrote:
Hi Johathan,

Do I understand it correctly that the primary motivation for this change in C23 and C++23 was that changing uintmax_t would be an ABI break, which is deemed unacceptable for the major compiler vendors?

Please stop framing opposition to ABI breaks to sound like a plot by evil vendors. There are many, many users who want their C programs to keep working, rather than start to have undefined behaviour because functions like imaxdiv silently change ABI. Vendors try to not introduce undefined behaviour into working code.

Because if the ABI issue didn't exist, it would indeed seem *conceptually* more correct to have __uint128_t be an integer type and uintmax_t to be 128 bit, would it not?

Yes, and implementations are free to do that, if they can support it for their users.

The reality was that __int128 has existed for many years and the definition of intmax_t has not changed. The standard should adapt to meet reality, not insist on conceptual purity.


On 29 Mar 2023, at 12:01, Jonathan Wakely via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

On Wed, 29 Mar 2023 at 09:45, Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Wed, Mar 29, 2023 at 12:07 AM Jonathan Wakely <cxx@kayari.org> wrote:
> You're assuming that __uint128_t is an integral type.

Do you remember Barney the Dinosaur? The big purple dinosaur guy that
sang songs on television with children, "I love you... you love

I can dress up in a big purple Barney suit, but that doesn't make me a
dinosaur. And I can put a miniature made-to-fit tuxedo on my dog, but
that doesn't make him a business man -- he's still a dog.

It doesn't matter if you're from another planet, or if your first
language isn't English, the type '__uint128_t' is an integer type. If
the C++ Standard, or if any given C++ compiler, doesn't recognise it
as an integer type, then that's a totally different issue.

Then take the discussion somewhere else, this list is about the C++ standard.


It isn't at all helpful to have false==std::is_integral_v<__int128>.
That's ridiculous. We know what an integer type is, we know what
128-Bit means, so __uint128_t is of course an integer type whose range
is 0 through 2^128-1 -- or an 'integral' type if you want to use the
adjectival/genitive form of the noun.

By definition, there are no integral types wider than uintmax_t, so if __int128 is wider than uintmax_t, it's not an integral type.

C++ implementations have to choose their poison, they can break the rule that uintmax_t is the largest type, or they can take an ABI break by changing uintmax_t, or they can provide wider types that are not classified as standard integer types. Until C++23 there is no way to do the right thing.

But we've fixed it now.

The expression 'is_integral_v<T>' should evaluate to true for any
compiler-built-in type that does mathematical operations on integers
(i.e. an integral type). Let's keep this simple.

We need to get our feet back on the ground and stop floating around up
in the clouds with abstract ideas. A rose is a rose is a rose. An
integer is an integer is an integer.

You said "There seems to be a bit of confusion about whether or not it's okay for uintmax_t to be 64-Bit if the compiler provides a 128-Bit integer type." I provided the background for that.

If you're not interested in understanding the reason for that confusion, and what the status quo is, and how it's been fixed for C23 and C++23, find another mailing list.

Std-Proposals mailing list