On 10/08/2020 20:50, Thiago Macieira wrote:
>>> On Monday, 10 August 2020 10:29:05 PDT language.lawyer_at_[hidden] wrote:
>>>> I meant that the result (value) of the lvalue-to-rvalue conversion
>>>> applied
>>>> to `*reinterpret_cast<unsigned char*>(&i)` (or
>>>> `*reinterpret_cast<unsigned*>(&i)`) is the value of `i`. Kind of, because
>>>> [expr.pre]/4 ([expr]/4) immediately tells that this is UB.
>>>
>>> Neither is true. The values are currently implementation-defined
>>
>> I'd like to see a proof.
>
> Here's one:
> int i = UCHAR_MAX + 2;
> unsigned char c = *reinterpret_cast<unsigned char *>(&i);
>
> If you are correct, this should produce c = uchar(UCHAR_MAX + 2)

You misunderstood something. I'm saying this is UB, not `uchar(UCHAR_MAX + 2)`. I don't claim that there is some cast applied to a [pr]value.

> , which is
> defined in the standard as (UCHAR_MAX + 2) modulo (UCHAR_MAX + 1), which
> equals 1. But it doesn't, on any big-endian machine.

This is not a proof of that the result currently is implementation-defined.
It is a proof that the Standard is prolly currently defective and doesn't reflect the behavior of most "ordinary" implementations.
Implementation-defined behavior must be explicitly marked as such and I'd expect to see it in https://timsong-cpp.github.io/cppwp/n4861/impldefindex

> For four examples and one
> little-endian just to see that the compiler isn't "seeing through" the test,
> see https://bigendian.godbolt.org/z/qjn7G5.