C++ Logo


Advanced search

Re: reading values as bytes without memcpu, from enum unsigned char?

From: language.lawyer_at <language.lawyer_at_[hidden]>
Date: Mon, 10 Aug 2020 20:29:05 +0300
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.

Received on 2020-08-10 12:32:40