Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: Legality of a++ = 1 ? (http://www.velocityreviews.com/forums/t869163-re-legality-of-a-1-a.html)

Ian Collins 03-08-2012 07:21 AM

Re: Legality of a++ = 1 ?
 
On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> Hi,
> I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and decrement operators.
>
> Why couldn't the semantics of this be: "a" is assigned "1", then "a" is incremented?
>
> gcc gives error: lvalue required as left operand of assignment



Because the result of a++ is a value, not a variable.

--
Ian Collins

Keith Thompson 03-08-2012 09:02 AM

Re: Legality of a++ = 1 ?
 
Ian Collins <ian-news@hotmail.com> writes:
> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
>> I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and decrement operators.
>>
>> Why couldn't the semantics of this be: "a" is assigned "1", then "a" is incremented?
>>
>> gcc gives error: lvalue required as left operand of assignment

>
> Because the result of a++ is a value, not a variable.


And because it's easy enough to write "a = 1 + 1;" or "a = 2;".

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Barry Schwarz 03-08-2012 05:50 PM

Re: Legality of a++ = 1 ?
 
On Mar 8, 4:53*am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
wrote:
> On 08/03/12 18:21, Ian Collins wrote:
>
> > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> >> Hi,
> >> I read ISO/IEC 9899:201x, section 6.5.2.4 Postfix increment and
> >> decrement operators.

>
> >> Why couldn't the semantics of this be: "a" is assigned "1", then "a"
> >> is incremented?

>
> >> gcc gives error: lvalue required as left operand of assignment

>
> > Because the result of a++ is a value, not a variable.

>
> Yes, if it's on the RHS. If there's no real legality problem, i might just let
> that exist as is instead of implementing extra code to disallow it;)


You can do anything you like when you build your own compiler. Just
be aware that the standard specifically states that the result of
modifying a twice wihtout an intervening sequence point is officially
undefined.

It is also a constraint violation and a diagnostic is required.

Harald van Dijk 03-08-2012 06:22 PM

Re: Legality of a++ = 1 ?
 
[ Legality of a++ = 1 ]
On Mar 8, 11:53*am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
wrote:
> On 08/03/12 18:21, Ian Collins wrote:
> > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> >> gcc gives error: lvalue required as left operand of assignment

>
> > Because the result of a++ is a value, not a variable.

>
> Yes, if it's on the RHS. If there's no real legality problem, i might just let
> that exist as is instead of implementing extra code to disallow it;)


No, it's always a value. If you can come up with a concrete sane
proposal for making a++ an lvalue and a description of what the
semantics should be, preferably without breaking existing valid code,
I will be very impressed.

James Kuyper 03-08-2012 07:11 PM

Re: Legality of a++ = 1 ?
 
On 03/08/2012 01:22 PM, Harald van Dijk wrote:
> [ Legality of a++ = 1 ]
> On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
> wrote:
>> On 08/03/12 18:21, Ian Collins wrote:
>>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
>>>> gcc gives error: lvalue required as left operand of assignment

>>
>>> Because the result of a++ is a value, not a variable.

>>
>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
>> that exist as is instead of implementing extra code to disallow it;)

>
> No, it's always a value. If you can come up with a concrete sane
> proposal for making a++ an lvalue and a description of what the
> semantics should be, preferably without breaking existing valid code,
> I will be very impressed.


Since use of a++ as an lvalue currently is a constraint violation, I
don't see how defining the meaning of such expressions could break
existing valid code - if the new meaning is relevant, the code is, by
definition, currently invalid.

He proposed the semantics in his first message. In more general terms,
he wants a++ = b to be equivalent to a = b + 1. Such semantics would
violate an important (but I think, unwritten) principle in the design of
the C language: evaluation of an expression consists of first evaluating
all of its sub-expressions, producing either values or lvalues. Then
evaluation of the higher level expression is defined in terms what it
does with those values and lvalues.
The proposed semantics for a++ = b can't be decomposed that way. This
isn't completely unprecedented: the semantics of &*p are defined as
being equivalent to p rather than &(*p). However, it's far easier to
deal with complete removal of semantics (as in &*p), than with the kind
of semantics proposed for a++ = b.

The expression a = b + 1 is allowed by the current standard, and is far
clearer than a++ = b. I can't see any reason to allow a++ = b, even if
we were designing a new language from scratch. As a modification to an
existing language, it doesn't come anywhere close to being sufficiently
well motivated.

Harald van Dijk 03-08-2012 07:28 PM

Re: Legality of a++ = 1 ?
 
On Mar 8, 8:11*pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 03/08/2012 01:22 PM, Harald van Dijk wrote:
> > [ Legality of a++ = 1 ]
> > On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
> > wrote:
> >> On 08/03/12 18:21, Ian Collins wrote:
> >>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> >>>> gcc gives error: lvalue required as left operand of assignment

>
> >>> Because the result of a++ is a value, not a variable.

>
> >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
> >> that exist as is instead of implementing extra code to disallow it;)

>
> > No, it's always a value. If you can come up with a concrete sane
> > proposal for making a++ an lvalue and a description of what the
> > semantics should be, preferably without breaking existing valid code,
> > I will be very impressed.

>
> Since use of a++ as an lvalue currently is a constraint violation, I
> don't see how defining the meaning of such expressions could break
> existing valid code - if the new meaning is relevant, the code is, by
> definition, currently invalid.


I assume that whatever is proposed, it would also make a++ an lvalue
in certain valid code where it is currently an rvalue. If not, then of
course you're right.

> He proposed the semantics in his first message. In more general terms,
> he wants a++ = b to be equivalent to a = b + 1.


I'm not asking for the semantics of the specific example a++ = b, I'm
asking for the semantics of a++ used as an lvalue in general. Even for
the example of a++ = b, I do not think I agree that he wants it to be
equivalent to (a = b + 1). I think he wants it to be equivalent to (a
= b, a++), except possibly unsequenced. The difference is that the
result of the assignment expression is the value of b, converted to
the type of a.

> Such semantics [snip]


I snipped this because you're assuming a specific exception for a++ =
b, while I'm assuming a more general rule for a++ that would (for
example) also allow &(a++). After all, the OP stated in a reply that
he would simply drop the error message from the compiler and let the
natural behaviour follow. Creating a specific exception for postfix ++
in an assignment expression is not the natural behaviour.

> The expression a = b + 1 is allowed by the current standard, and is far
> clearer than a++ = b. I can't see any reason to allow a++ = b, even if
> we were designing a new language from scratch. As a modification to an
> existing language, it doesn't come anywhere close to being sufficiently
> well motivated.


Agreed.

Harald van Dijk 03-08-2012 08:06 PM

Re: Legality of a++ = 1 ?
 
On Mar 8, 8:56*pm, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 3/8/2012 1:22 PM, Harald van Dijk wrote:
> > [ Legality of a++ = 1 ]
> > On Mar 8, 11:53 am, Russell Shaw<rjshawN_o@s_pam.netspace.net.au>
> > wrote:
> >> On 08/03/12 18:21, Ian Collins wrote:
> >>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> >>>> gcc gives error: lvalue required as left operand of assignment

>
> >>> Because the result of a++ is a value, not a variable.

>
> >> Yes, if it's on the RHS. If there's no real legality problem, i might just let
> >> that exist as is instead of implementing extra code to disallow it;)

>
> > No, it's always a value. If you can come up with a concrete sane
> > proposal for making a++ an lvalue and a description of what the
> > semantics should be, preferably without breaking existing valid code,
> > I will be very impressed.

>
> And, if "a++" becomes an lvalue, what about "(a+=1)"?


There is little problem in practise making (a+=1) and (++a) lvalues. C+
+ has done so for both, so we know it's possible.

> This, of course, also ignores the part about modifying something twice
> between sequence points. *(Does "a++ = 1;" result in "a" being 1 or 2? *And
> if you're leaving it UB, what's the point in allowing it in the first place?)


Quoting the original message:

"Why couldn't the semantics of this be: "a" is assigned "1", then
"a" is incremented?"

So it would, as far as I can tell the OP is concerned, result in "a"
being 2.

Keith Thompson 03-08-2012 08:11 PM

Re: Legality of a++ = 1 ?
 
Harald van Dijk <haraldvdijk@gmail.com> writes:
> [ Legality of a++ = 1 ]
> On Mar 8, 11:53*am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
> wrote:
>> On 08/03/12 18:21, Ian Collins wrote:
>> > On 03/ 8/12 11:52 AM, Russell Shaw wrote:
>> >> gcc gives error: lvalue required as left operand of assignment

>>
>> > Because the result of a++ is a value, not a variable.

>>
>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
>> that exist as is instead of implementing extra code to disallow it;)

>
> No, it's always a value. If you can come up with a concrete sane
> proposal for making a++ an lvalue and a description of what the
> semantics should be, preferably without breaking existing valid code,
> I will be very impressed.


For what it's worth, in C++ ++a is an lvalue (but a++ isn't).

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper 03-08-2012 08:42 PM

Re: Legality of a++ = 1 ?
 
On 03/08/2012 02:28 PM, Harald van Dijk wrote:
> On Mar 8, 8:11 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 03/08/2012 01:22 PM, Harald van Dijk wrote:
>>> [ Legality of a++ = 1 ]
>>> On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
>>> wrote:
>>>> On 08/03/12 18:21, Ian Collins wrote:
>>>>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
>>>>>> gcc gives error: lvalue required as left operand of assignment

>>
>>>>> Because the result of a++ is a value, not a variable.

>>
>>>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
>>>> that exist as is instead of implementing extra code to disallow it;)

>>
>>> No, it's always a value. If you can come up with a concrete sane
>>> proposal for making a++ an lvalue and a description of what the
>>> semantics should be, preferably without breaking existing valid code,
>>> I will be very impressed.

>>
>> Since use of a++ as an lvalue currently is a constraint violation, I
>> don't see how defining the meaning of such expressions could break
>> existing valid code - if the new meaning is relevant, the code is, by
>> definition, currently invalid.

>
> I assume that whatever is proposed, it would also make a++ an lvalue
> in certain valid code where it is currently an rvalue. If not, then of
> course you're right.


The standard doesn't use the term rvalue; it just uses the word value
for that purpose. For a++ to be an lvalue, is, in itself, no more of a
problem than the fact that 'a' itself is an lvalue. That fact doesn't
prevent you from using 'a' in contexts where a value is required. The
C++ standard talks about such things in terms of an implicit lvalue to
rvalue conversion, but the C standard doesn't even bother with that.
Lvalue expressions act as lvalues when they need to, and otherwise
simply have ordinary values.

>> He proposed the semantics in his first message. In more general terms,
>> he wants a++ = b to be equivalent to a = b + 1.

>
> I'm not asking for the semantics of the specific example a++ = b, I'm
> asking for the semantics of a++ used as an lvalue in general.


My point was that the proposed semantics for a++ = b cannot be broken up
into an lvalue returned by a++ that is used as a destination for = to
write to. We don't need to even think about a++.member, and &a++ would
presumably be equivalent to (a++, &a). The only other contexts where an
lvalue is needed are more problematic:

a++++ = b;
a++-- = b;
a--++ = b;
a---- = b;

++a++ = b;
++a-- = b;
--a++ = b;
--a-- = b;

++++a = b;
++--a = b;
--++a = b;
----a = b;

and I have no idea what he wants done with those cases.

> ... Even for
> the example of a++ = b, I do not think I agree that he wants it to be
> equivalent to (a = b + 1). I think he wants it to be equivalent to (a
> = b, a++), except possibly unsequenced. ..


His description is consistent only with it being sequenced. If the
side-effect of a++ occurred before that of a=b, it wouldn't match his
description.

>.. The difference is that the
> result of the assignment expression is the value of b, converted to
> the type of a.


He didn't say anything about the type or value of the expression as a
whole. I suspect he's not given it much thought, and I didn't either.
The possibilities that are consistent with what he said, which make
sense to me, include (a = b + 1), (a=b,a++), or (__temp = a, a=b, a++,
__temp), where __temp is a variable of the same type as 'a'. He might
have had something else in mind.

Harald van Dijk 03-08-2012 09:10 PM

Re: Legality of a++ = 1 ?
 
On Mar 8, 9:42*pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 03/08/2012 02:28 PM, Harald van Dijk wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 8, 8:11 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> On 03/08/2012 01:22 PM, Harald van Dijk wrote:
> >>> [ Legality of a++ = 1 ]
> >>> On Mar 8, 11:53 am, Russell Shaw <rjshawN_o@s_pam.netspace.net.au>
> >>> wrote:
> >>>> On 08/03/12 18:21, Ian Collins wrote:
> >>>>> On 03/ 8/12 11:52 AM, Russell Shaw wrote:
> >>>>>> gcc gives error: lvalue required as left operand of assignment

>
> >>>>> Because the result of a++ is a value, not a variable.

>
> >>>> Yes, if it's on the RHS. If there's no real legality problem, i might just let
> >>>> that exist as is instead of implementing extra code to disallow it;)

>
> >>> No, it's always a value. If you can come up with a concrete sane
> >>> proposal for making a++ an lvalue and a description of what the
> >>> semantics should be, preferably without breaking existing valid code,
> >>> I will be very impressed.

>
> >> Since use of a++ as an lvalue currently is a constraint violation, I
> >> don't see how defining the meaning of such expressions could break
> >> existing valid code - if the new meaning is relevant, the code is, by
> >> definition, currently invalid.

>
> > I assume that whatever is proposed, it would also make a++ an lvalue
> > in certain valid code where it is currently an rvalue. If not, then of
> > course you're right.

>
> The standard doesn't use the term rvalue; it just uses the word value
> for that purpose. For a++ to be an lvalue, is, in itself, no more of a
> problem than the fact that 'a' itself is an lvalue. That fact doesn't
> prevent you from using 'a' in contexts where a value is required.


Agreed, but the description of the lvalue-postfix-++ would need to be
phrased in such a way that the lvalue-to-rvalue conversion (sorry, the
lvalue-to-value conversion) is applied before the side effect of ++
has taken place, in those cases where currently the result of a++
would be used directly as a value.

> The
> C++ standard talks about such things in terms of an implicit lvalue to
> rvalue conversion, but the C standard doesn't even bother with that.
> Lvalue expressions act as lvalues when they need to, and otherwise
> simply have ordinary values.


The C standard pretty much calls it an lvalue-to-value conversion in
6.3.2.1p2: "An lvalue that [...] is converted to the value stored in
the designated object [...]".

> >> He proposed the semantics in his first message. In more general terms,
> >> he wants a++ = b to be equivalent to a = b + 1.

>
> > I'm not asking for the semantics of the specific example a++ = b, I'm
> > asking for the semantics of a++ used as an lvalue in general.

>
> My point was that the proposed semantics for a++ = b cannot be broken up
> into an lvalue returned by a++ that is used as a destination for = to
> write to.


The evaluation of a++ could return a as an lvalue, and schedule the
side effect of (a += 1) at some as of yet unspecified later time.
Needlessly complicated for code that deserves to be broken, but not
impossible.

> We don't need to even think about a++.member,


++ cannot be applied to structures or unions in C, but in C++, if a
class defines a custom postfix ++ operator, a++.member is valid but
typically retrieves the member from the rvalue structure result.

> and &a++ would
> presumably be equivalent to (a++, &a)


That's not what I would expect. If &a++ is equivalent to (a++, &a),
then *&a++'s value is different from that of a++.

>. The only other contexts where an
> lvalue is needed are more problematic:
>
> * * * * a++++ = b;
> * * * * a++-- = b;
> * * * * a--++ = b;
> * * * * a---- = b;
>
> * * * * ++a++ = b;
> * * * * ++a-- = b;
> * * * * --a++ = b;
> * * * * --a-- = b;
>
> * * * * ++++a = b;
> * * * * ++--a = b;
> * * * * --++a = b;
> * * * * ----a = b;
>
> and I have no idea what he wants done with those cases.


Interestingly, in C++, the prefix ++ and -- operators can be combined
in exactly the way you describe.

> > ... Even for
> > the example of a++ = b, I do not think I agree that he wants it to be
> > equivalent to (a = b + 1). I think he wants it to be equivalent to (a
> > = b, a++), except possibly unsequenced. ..

>
> His description is consistent only with it being sequenced. If the
> side-effect of a++ occurred before that of a=b, it wouldn't match his
> description.


Good point.

> >.. The difference is that the
> > result of the assignment expression is the value of b, converted to
> > the type of a.

>
> He didn't say anything about the type or value of the expression as a
> whole. I suspect he's not given it much thought, and I didn't either.


For whatever reason, I did. Or tried to, anyway.

> The possibilities that are consistent with what he said, which make
> sense to me, include (a = b + 1), (a=b,a++), or (__temp = a, a=b,a++,
> __temp), where __temp is a variable of the same type as 'a'. He might
> have had something else in mind.


Another possibility: if a++ is an lvalue, why can't a = b, and
therefore a++ = b be too?


All times are GMT. The time now is 12:50 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.