Legality of a++ = 1 ?

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:

> 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

(a=1)++ may work.

If you don't like this, overload the operators "=" and "++" for
a, if that's an object of your class.

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

"Russell Shaw" <rjshawN_o@s_pam.netspace.net.au> wrote in message
news:fqso29-i63.ln1@news.anatron.com.au...
>>>>> [ Legality of a++ = 1 ]

> I am writing a C compiler and it can be hard to pinpoint answers in the
> C99 standard. 6.5.2, 6.5.3, and its footnotes looks like a relevent answer
> to disallowing a reliable sequence of operations for a++ = b.

Then it depends on whether A++ can be an lvalue. The 'A' part will be
(otherwise you wouldn't be able to use ++ on it). But it's lvalue-ness is
already expended on '++'; Can you re-use this value on the result of the
whole 'A++' term?

If you can, then you will also be able to do &(A++), and A++ ++ ++, and all
sorts of weird stuff. But some of this, including A++=B would be changing a
variable twice between sequence points (which is a big no-no in C).

Apart from which, no-one looking at A++=B would have a clue what it's
supposed to mean. So if mainstream compilers won't accept it, then I would
just forget about it.

> Half the effort is in figuring out whether something that is technically
> doable is politically allowed by the standard.

It is very tempting when writing compilers to improve on the language,
especially it is trivial to do so. But any sorts of extensions to C are
usually frowned upon, unless ratified by a committee. Or you can just
forget the Standard...

--
Bartc

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:
<snip>
> I am writing a C compiler and it can be hard to pinpoint answers in
> the C99 standard. 6.5.2, 6.5.3, and its footnotes looks like a
> relevent answer to disallowing a reliable sequence of operations for
> a++ = b.

6.5.16.1 (simple assignment) is also important, of course. But C
disallows very little. The often feared "undefined behaviour" just
means that the C standard has nothing to say on the matter, so you are
free to do what you like in undefined situations.

a++ = b is a constraint violation so a diagnostic is required, but it
does not even have to relate to that piece of code. Your compiler could
announce at the start:

"This compiler accepts extensions to the C language."

and you will have conformed to the letter of the standard. Of course,
people like to be told where their code uses extensions, so something
more specific is helpful, despite not being required.

In this case, though, I have to wonder what the advantage of allowing
a++ = b is. It's not expensive to check since lvalue-ness (if I you can
forgive such an ugly term) is a property of syntactic forms. You can
flag up things like this with very little extra code at all.

> Half the effort is in figuring out whether something that is
> technically doable is politically allowed by the standard.

--
Ben.

XeCycle <XeCycle@Gmail.com> writes:

> Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:
>
>> 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
>
> (a=1)++ may work.

This remark confused me until I saw:

> If you don't like this, overload the operators "=" and "++" for
> a, if that's an object of your class.

You are talking about C++, but the question was about C. This is, after
all, comp.lang.c.

--
Ben.

On 09/03/12 22:47, Ben Bacarisse wrote:
> Russell Shaw<rjshawN_o@s_pam.netspace.net.au> writes:
> <snip>
>> I am writing a C compiler and it can be hard to pinpoint answers in
>> the C99 standard. 6.5.2, 6.5.3, and its footnotes looks like a
>> relevent answer to disallowing a reliable sequence of operations for
>> a++ = b.
>
> 6.5.16.1 (simple assignment) is also important, of course. But C
> disallows very little. The often feared "undefined behaviour" just
> means that the C standard has nothing to say on the matter, so you are
> free to do what you like in undefined situations.
>
> a++ = b is a constraint violation so a diagnostic is required, but it
> does not even have to relate to that piece of code. Your compiler could
> announce at the start:
>
> "This compiler accepts extensions to the C language."
>
> and you will have conformed to the letter of the standard. Of course,
> people like to be told where their code uses extensions, so something
> more specific is helpful, despite not being required.
>
> In this case, though, I have to wonder what the advantage of allowing
> a++ = b is. It's not expensive to check since lvalue-ness (if I you can
> forgive such an ugly term) is a property of syntactic forms. You can
> flag up things like this with very little extra code at all.

Hi,
I was not purposely allowing a++ = b, but wondering if it had good behaviour
defined by the standard (it appears not).

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnpqcm4zuz.fsf@nuthaus.mib.org...
> Harald van Dijk <haraldvdijk@gmail.com> writes:
>> [ Legality of a++ = 1 ]

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

How would the ++a work? Like this:

int a=1000;

++a += 3; // a is now 1004?

--
Bartc

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnpqcm4zuz.fsf@nuthaus.mib.org...
>> Harald van Dijk <haraldvdijk@gmail.com> writes:
>>> [ Legality of a++ = 1 ]
>
>>> 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).
>
> How would the ++a work? Like this:
>
> int a=1000;
>
> ++a += 3; // a is now 1004?

I get 1004 using the g++ compiler -- but as in C, modifying an object
twice without an intervening sequence point has undefined behavior.

I think the usefulness of allowing ++a to be an lvalue shows up when
"++" is an overloaded operator.

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

On Mar 9, 8:17*pm, Keith Thompson <ks...@mib.org> wrote:
> "BartC" <b...@freeuk.com> writes:
> > "Keith Thompson" <ks...@mib.org> wrote in message
> >> For what it's worth, in C++ ++a is an lvalue (but a++ isn't).
>
> > How would the ++a work? Like this:
>
> > int a=1000;
>
> > ++a += 3; * *// a is now 1004?

Yes.

> I get 1004 using the g++ compiler -- but as in C, modifying an object
> twice without an intervening sequence point has undefined behavior.

C++ introduces sequence points after the side effect for prefix ++.
(Actually, it does so for a += 1, and ++a is defined to be equivalent
to a += 1.) It has to, or the lvalue-to-rvalue conversion in a = ++b
would be undefined. The example of a ^= b ^= a ^= b, given in the C
FAQ as an example of undefined behaviour, is valid in C++.

> I think the usefulness of allowing ++a to be an lvalue shows up when
> "++" is an overloaded operator.

When ++ is an overloaded operator, the overloaded operator determines
the type and lvalue-ness of the result. That's no reason why the built-
in types' prefix ++ should return lvalues.