> On big-endian systems we'll end up with `ch==0`; on little-endian systems we'll have `ch==42`.I think not - the value of the int object does not truncate. It's value is 42.
-------- Original message --------From: Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]> Date: 8/21/19 17:30 (GMT-05:00) To: std-proposals_at_[hidden] Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> Subject: Re: [std-proposals] Allowing access to object representations 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