On 10/08/2020 20:18, Thiago Macieira wrote:
> On Monday, 10 August 2020 09:45:20 PDT language.lawyer_at_[hidden] wrote:
>>> And that's still different from the above because of the type. One is
>>> unsigned char (a byte) which is allowed by the standard to alias
>>> everything. The other isn't.
>>
>> The type is different, but `unsigned int` is allowed to alias `int`.
>
> Where does it say that?

Who "it"? The Standard? https://timsong-cpp.github.io/cppwp/n4861/basic.lval#11.2

>>>>> The issue is that the value is not well-specified by the standard.
>>>>
>>>> The value is 100% specified by the standard. It is the value of `i`,
>>>> which
>>>> is `UCHAR_MAX + 1`.
>>>
>>> If you meant that the value of i is the value of i, then it's
>>> tautological.
>>
>> 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.
  
>>> If you meant that the value of a uchar resulting from this conversion
>>> should be defined by the standard, then it's impossible nonsense.
>>
>> I didn't mean how it should be defined, I wrote how it is currently
>> [un]defined.
>
> It should be defined to be implementation-defined or unspecified.
>
>>> The value is neither specified
>>
>> How https://timsong-cpp.github.io/cppwp/n4659/conv.lval#3.4 is "not
>> specified"?
>
> It's just irrelevant, because it doesn't apply to this case.