Subject: Re: reading values as bytes without memcpu, from enum unsigned char?
From: Thiago Macieira (thiago_at_[hidden])
Date: 2020-08-10 12:18:55
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?
> >>> 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, not the
value of i converted to the target type.
> > 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
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
It's just irrelevant, because it doesn't apply to this case.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
STD-DISCUSSION list run by firstname.lastname@example.org
Older Archives on Google Groups