Date: Wed, 21 Aug 2019 21:44:07 +0200
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!
Cheers,
Timur
> On 21 Aug 2019, at 21:33, sdkrystian via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Ah, ignore my example then.
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: "language.lawyer--- via Std-Proposals" <std-proposals_at_[hidden]>
> Date: 8/21/19 15:31 (GMT-05:00)
> To: std-proposals_at_[hidden]
> Cc: language.lawyer_at_[hidden]
> Subject: Re: [std-proposals] Allowing access to object representations
>
> On 21/08/2019 22:11, Timur Doumler wrote:
> > This doesn't make sense to me.
>
> That's why some people think this should be fixed.
>
> > If I have an object of type int (or, say, a struct containing an int), then the value has 4 bytes. If I access that value by dereferencing a char pointer that aliases that object, all I can ever get from that char is a single byte. How can this be "the object"?
>
> The standard just says what result you get, it is an implementation's problem to answer the "how" question.
> However, http://eel.is/c++draft/expr.pre#4 could help some implementations:
> > If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.
>
> If you have an int object and try to access its value through a char lvalue and the value stored in the int object is not in the range representable by the char type, the behavior is undefined.
>
> [expr.pre]/4 helps little-endian machine implementations, because they just can fetch the first byte of the int object and this would give the right value when there is no UB.
> IDK how a big-endian maching implementation can achieve the standard-conforming behavior :-)
>
> > Cheers,
> > Timur
> >
> >> On 21 Aug 2019, at 20:59, language.lawyer--- via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >>
> >>> On 21/08/2019 21:55, Krystian Stasiowski via Std-Proposals wrote:
> >>> Yes, you access the value of the object of the object, however, since its not specified what exactly you get
> >>
> >> It is specified: you get the value contained in the object.
> >>
> >>> http://eel.is/c++draft/conv.lval#3.4
> >>
> >> Indeed, it is specified here.
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
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!
Cheers,
Timur
> On 21 Aug 2019, at 21:33, sdkrystian via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Ah, ignore my example then.
>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: "language.lawyer--- via Std-Proposals" <std-proposals_at_[hidden]>
> Date: 8/21/19 15:31 (GMT-05:00)
> To: std-proposals_at_[hidden]
> Cc: language.lawyer_at_[hidden]
> Subject: Re: [std-proposals] Allowing access to object representations
>
> On 21/08/2019 22:11, Timur Doumler wrote:
> > This doesn't make sense to me.
>
> That's why some people think this should be fixed.
>
> > If I have an object of type int (or, say, a struct containing an int), then the value has 4 bytes. If I access that value by dereferencing a char pointer that aliases that object, all I can ever get from that char is a single byte. How can this be "the object"?
>
> The standard just says what result you get, it is an implementation's problem to answer the "how" question.
> However, http://eel.is/c++draft/expr.pre#4 could help some implementations:
> > If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.
>
> If you have an int object and try to access its value through a char lvalue and the value stored in the int object is not in the range representable by the char type, the behavior is undefined.
>
> [expr.pre]/4 helps little-endian machine implementations, because they just can fetch the first byte of the int object and this would give the right value when there is no UB.
> IDK how a big-endian maching implementation can achieve the standard-conforming behavior :-)
>
> > Cheers,
> > Timur
> >
> >> On 21 Aug 2019, at 20:59, language.lawyer--- via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >>
> >>> On 21/08/2019 21:55, Krystian Stasiowski via Std-Proposals wrote:
> >>> Yes, you access the value of the object of the object, however, since its not specified what exactly you get
> >>
> >> It is specified: you get the value contained in the object.
> >>
> >>> http://eel.is/c++draft/conv.lval#3.4
> >>
> >> Indeed, it is specified here.
> >> --
> >> Std-Proposals mailing list
> >> Std-Proposals_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2019-08-21 14:46:13