On 25/08/2019 03:06, sdkrystian via Std-Proposals wrote:
> That is my interpretation as well, but one would think the intent is that it applies to all value categories as well. After all, the standard has trouble with the most commonly used definitions (such as variable, which is referred to as having properties of an object/reference, as well as being an object/reference (it's not!) or even the result of a glvalue being a value http://eel.is/c++draft/expr.context#2.sentence-8)

I think [expr.context]/2 should say "its result is discarded".
Would you like to open an issue or maybe even propose the fix in a PR?

>
>
>
> Sent from my Samsung Galaxy smartphone.
>
> -------- Original message --------
> From: "language.lawyer--- via Std-Proposals" <std-proposals_at_[hidden]>
> Date: 8/24/19 19:53 (GMT-05:00)
> To: std-proposals_at_[hidden]
> Cc: language.lawyer_at_[hidden]
> Subject: Re: [std-proposals] Allowing access to object representations
>
> On 25/08/2019 02:47, sdkrystian via Std-Proposals wrote:
> > > However, there is no analog of [expr.pre]/4 for assignment.
> >
> > It depends on how you interpret it. Assignment yields a glvalue, which will be evaluated (unless in an unevaluated context) and its result is an object - whether or not you interpret "[...] result is not mathematically defined or not in the range of representable values [...]" as applying uniformly to all value categories (prvalues, or in the case of an glvalue, the value of the result) or if it only applies to prvalues will change the meaning.
>
> I like interpreting it as applying only to prvalues.
> Because prvalues has values as their _result_ (http://eel.is/c++draft/basic.lval#def:result,prvalue)
>
> > -------- Original message --------
> > From: "language.lawyer--- via Std-Proposals" <std-proposals_at_[hidden]>
> > Date: 8/24/19 17:35 (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:31, language.lawyer_at_[hidden] wrote:
> > > 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.
> >
> > However, there is no analog of [expr.pre]/4 for assignment.
> > In the code
> >
> > int x = WHATEVER;
> > *reinterpret_cast<char*>(&x) = 0;
> >
> > the value of `x` shall become `0`.
> > --
> > 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
>