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
> [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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering