Problem with an ANSI specification

[daudiam]

There is a rule about sequence point that goes like this.

"Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored."

What bugs me is the last sentence.

In the case of
a=c++;

the object whose value is getting modified is 'c'; the value of c is getting incremented. But, the old value of c is being passed to a, when the rule says that the prior value of c should only be used for determining the value to be stored in c (in this case, it should only be used for incrementing c) not for any other purpose. How is it that the old value is being used for another purpose

These cases are common, as there are often expressions of the form : [code=c] d=e/c++;

where the prior value of c is being used as the divisor of e.[code=c] a=c++;

the object whose value is getting modified is 'c'; the value of c is getting incremented. But, the old value of c is being passed to a, when the rule says that the prior value of c should only be used for determining the value to be stored in c (in this case, it should only be used for incrementing c) not for any other purpose. How is it that the old value is being used for another purpose

These cases are common, as there are often expressions of the form :
d=e/c++;

where the prior value of c is being used as the divisor of e.[code=c] d=e/c++;

where the prior value of c is being used as the divisor of e.

[Narue]

For the record, C is defined by ISO, not ANSI. Control of the language standard was taken over by ISO in 1990. The language that everyone refers to as "C89" is actually ISO C90 with the 1995 addendum. So C90 or C95 are more strictly correct (though not as well recognized). Then of course there's the ISO C99 standard, and the future C1x standard. The current official standard is C99 and the de facto standard is C95.

>But, the old value of c is being passed to a, when the
>rule says that the prior value of c should only be used
>for determining the value to be stored in c
For a = c++; , c is not being accessed twice. The value being assigned to a is the result of the expression c++ , not the value stored in c.

[daudiam]

c++ happens in the following steps :

1. temp=c;
2. c=c+1;
3. return temp;

So in essence, the old value of c is being used for storing in a temporary variable AS WELL as for incrementing c, whereas the standard says that the prior value of c should be accessed ONLY for determining the values to be stored.

"Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored."

Also, can u please give an example where the first statement of the above standard holds, but not the second.

Thanks.

[Ancient Dragon]

An example you can see here occasionally a = c++ + ++c; The result of that expression is undefined because (most likely) it violates the rules you cited. Consequently the result store in a will be whatever the compiler writer decided it to be.

[daudiam]

Anyone please !

[Narue]

>Anyone please !
You're starting to get annoying. Read the answers you've been given and try to understand them before shooting back for clarification. Your question has been answered, if you'd bother to read for comprehension. If you don't engage your brain, I'll stop trying to help you, regardless of how promising your questions are.

[daudiam]

I try my best to understand. Perhaps, I'm not able to put my questions correctly, and that's why I don't get the answers I was seeking for, so I end up keep asking the same thing, putting it in different ways.

but, thanks anyway !

[xavier666]

An example you can see here occasionally a = c++ + ++c; The result of that expression is undefined because (most likely) it violates the rules you cited. Consequently the result store in a will be whatever the compiler writer decided it to be.

It recently came to my light about the functioning of a +++++ b, so I've decided to share

What does a+++++b mean?

The only meaningful way to parse this is:

a ++  +  ++  b

However, the maximal munch rule requires it to be broken down as:

a ++  ++  +  b

This is syntactically invalid:
it is equivalent to:

((a++)++) +  b

But the result of a++ is not an lvalue and hence is not acceptable as an operand of ++. Thus the rules for resolving lexical ambiguity make it impossible to resolve this example in a way that is syntactically meaningful. In practice, of course, the prudent thing to do is to avoid construction like this unless you are absolutely certain what they mean. Of course, adding whitespace helps the compiler to understand the intent of the statement, but it is preferable (from a code maintenance perspective) to split this construct into more than one line:

++b;
(a++) + b;

-Taken from Shiv Dutta's article on Best Practices For Programming. (Shiv Dutta - Technical Consultant, IBM, Software Group)

Source

[Narue]

>It recently came to my light about the functioning of a +++++ b, so I've decided to share
Thanks for sharing, but you are aware that this tidbit is irrelevant to the topic, right?