C++ Logo


Advanced search

Subject: Re: [std-proposals] Allowing access to object representations
From: language.lawyer_at_[hidden]
Date: 2019-08-21 16:34:25

On 22/08/2019 00:30, Arthur O'Dwyer via Std-Proposals wrote:
> On Wed, Aug 21, 2019 at 4:37 PM language.lawyer--- via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
> On 21/08/2019 22:51, language.lawyer_at_[hidden] <mailto: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.)

I'm also "under the impression" that the Standard requires `ch == 42`.

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

STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups