C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Allowing access to object representations
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2019-08-21 16:30:03


On Wed, Aug 21, 2019 at 4:37 PM language.lawyer--- via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 21/08/2019 22:51, language.lawyer_at_[hidden] wrote:
> > On 21/08/2019 22:44, Timur Doumler via Std-Proposals wrote:
> >> So you're saying that, even without any pointer arithmetic, just this
> code:
> >>
> >> int x = 100000;
> >> std::cout << *reinterpret_cast<char*>(&x);
> >>
> >> has undefined behaviour?
> >>
> >> If that's the case then this is even more insane than I thought. Please
> clarify whether this is really what you're saying here!
> >
> > I suspect you was trying to answer my mail, but anyways yes, I think
> that your example has UB.
>
> UB if 100000 is outside of the range representable by char, ofc.
> On a platform where char represents the same range of values as int the
> code obviously won't have UB.
>

Well, regardless of your views on UB, we can all agree that the behavior of
    int x = 42;
    char ch = *reinterpret_cast<char*>(&x);
is not portable. On big-endian systems we'll end up with `ch==0`; on
little-endian systems we'll have `ch==42`. (This contradicts something
sdkrystian said earlier; he seemed to be under the impression that `ch==42`
always.)

Whether the integer value of `x` happens to be less than CHAR_MAX doesn't
matter at all; the behavior is implementation-defined at best — and UB at
worst. I'm inclined to believe the people who say it's UB, because in my
experience pretty much anything involving `reinterpret_cast` is UB.

However, all is not lost — it'll still do what you expect, in practice! :)

–Arthur



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups