On Wed, 29 Mar 2023 at 10:16, Timur Doumler <cpp_at_[hidden]> 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.


>
> Cheers,
> Timur
>
> On 29 Mar 2023, at 12:01, Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> 
>
>
> On Wed, 29 Mar 2023 at 09:45, Frederick Virchanza Gotham via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
>> On Wed, Mar 29, 2023 at 12:07 AM Jonathan Wakely <cxx_at_[hidden]> 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
>> me..."?
>>
>> 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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>