I agree with you.
the result of "reinterpret_cast<unsigned char*>(&i);" still point to
the original object (i), that is `i` due to:
>Otherwise, if the original pointer value points to an object a, and there is an object b of type T (ignoring cv-qualification) that is pointer-interconvertible with a, the result is a pointer to b. Otherwise, the pointer value is unchanged by the conversion.

Because "reinterpret_cast<unsigned char*>(&i);" is simply equivalent
to `static_cast<unsigned char*>(static_cast<void*>(&i))`.

And according to the rule for operator *:
>The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points.

Hence, the the resulting glvalue refers to the object `i`, and what
the value of such object is specified by the following rule:
>Otherwise, the value contained in the object indicated by the glvalue is the prvalue result.

So, the value of the result of such expression
"*reinterpret_cast<unsigned char*>(&i);" is the value contained in the
object i to which the glvalue refer. It's my reading.

language.lawyer--- via Std-Discussion
<std-discussion_at_[hidden]> 于2020年8月8日周六 上午3:12写道：
>
> >>> Just to spell it out, this is fine:
> >>>
> >>> ```
> >>> auto ptr = new AnyType(...);
> >>> auto byte_ptr = reinterpret_cast<unsigned char*>(ptr);
> >>> *byte_ptr;
> >>> ```
> >>
> >> *byte_ptr; doesn't access anything. lvalue-to-rvalue conversion is not applied to a discarded-value expression of non-volatile type.
> >> But anyway, assuming we have access there, that code can haz UB. More specific example:
> >> ```
> >> int i = UCHAR_MAX + 1;
> >> auto uc = *reinterpret_cast<unsigned char*>(&i); // UB because of [expr.pre]/4
> >> ```
> >
> > I don't see how [expr]/4 applies here. You're accessing an `unsigned
> > char` in a place where there is no `unsigned char` object. There's no
> > expectation that this value won't be "mathematically defined" or
> > otherwise "not in the range of representable values for its type". So
> > it's not UB by [expr]/4.
>
> See my analysis of a similar code https://lists.isocpp.org/sg12/2019/06/0802.php
>
> > 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`.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion