Subject: Re: reading values as bytes without memcpu, from enum unsigned char?
From: jim x (xmh970252187_at_[hidden])
Date: 2020-08-20 03:17:12
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 list run by firstname.lastname@example.org
Older Archives on Google Groups