I have a question about ansi c

[dayanike]

Hi guys I have a textbook question about ansi c and I could not understand the answer.is there anyone who can help me ?

question :
determine the values of i,j,k after execution of the following program frangment:

int i,j,k:
i=j=k=1;
i-=-j-------k;


the answer according to book is i=2 but why ?

[Rodaxoleaux]

i-=-j-------k;

What has science done?

i - (-j) (ignoring that bullcrap after it)

1 - (-1) = 2

Also you ended line 3 with a colon instead of a semi-colon and the random ----------k so... yeah...

[oogabooga]

It doesn't compile. The only sensible thing I can make out of it that's close is

i -= - j-- - --k;

which gives i=2, j=0, k=0
but I had to remove two minus signs.

[Rodaxoleaux]

Ohhhhh. I see it now. That's horribly formatted.

[pheininger]

As others have pointed out the first line with the variable defintions should end with a colon. I assumed that was a typo and replaced it with a semi-colon.

So now concentrating on the primary line:

i-=-j-------k;

As someone has already point out, this poorly formated. No real code should be written with that many operators in a row with out spaces and/or parentheses to emphasize the programmers intent.

I ran this through two different compilers which gave the same diagnostics. The rest of this is my analysis of the source of those diagnostics.

The rest of the references are based on the C99 standard in the form of the JTC1/SC22/WG14 working document N1256 which includes the C99 standard with the three Technical Corrigendum included.

I have added spaces to separate the preprocessor tokens as I understand section 6.4 paragraphs 4 through 6:

i -= - j -- -- -- - k;

So based on operator precedence based on the grammar in section 6.5 and its subsections, I believe the inner most expression is:

j --

I do not see a problem with this; it returns the value in j and then decrements it.

However, when we add the second postfix decrement operator (see below), we now have an error. From section 6.5.2.4 paragraph 1, "The operand of the postfix .... decrement operator shall have qualified or unqualified real or pointer type and shall be a modifiable lvalue." And from section 6.3.2.1 paragraph 2, "Except when it is the operand of ..., the -- operator, or ..., an lvalue that does not have array type is converted to the value stored in the designated object (and is no longer an lvalue)." (Emphasis added in both quotations.)

j -- --

The error is repeated for the third postfix decrement operator. So this code segment will not compile on a C99 compliant compiler. (I suspect that the same is true for a C89 compiler, but I do not have access to that standard.)

And if this was not a translation error, we are modifying j three times between sequence points and that would be undefined behavior.

So in my opinion your book is wrong. However, you may want to check if your book as a published errata sheet. They may have already recognized their error.

[quzah]

I have added spaces to separate the preprocessor tokens

There are no preprocessor tokens there. Even if there were, you would have no way of knowing if this: j------k is:

a) j - -- -- k
b) j -- - -- k
c) j -- -- - k

You can't do this: j-- --; "invalid lvalue in decrement".


Quzah.

[pheininger]

There are no preprocessor tokens there.

This is an example why the standard is a standard and not training material. And any code where you have to be a language lawyer to explain it (like I did earlier in the thread) needs to be rewritten. Back to language lawyer mode for a few minutes.

Yes, there are no preprocessing directives here (section 6.10) but there are preprocessing tokens (described in section 6.4 paragraph 3). [I incorrectly used the term preprocessor tokens when the standard term is preprocessing tokens.] They are
preprocessing tokens in translation phases 3 through 6 and then become just tokens in phases 7 and 8. (in section 6.4 paragraph 3, translation phases are defined in 5.1.1.2).

Even if there were, you would have no way of knowing if this: j------k is:

a) j - -- -- k
b) j -- - -- k
c) j -- -- - k

You can't do this: j-- --; "invalid lvalue in decrement".

I am going to assume that you meant 5 hyphens in all four examples.

If I were maintaining this code, I do not know what the original programmer meant. (Since it won't compile, it will probably not get to maintanence any how.) But the standard gives us a direction. Section 6.4 paragraph 4 says "If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token. There is one exception to this rule: a header name preprocessing token is only recognized within a #include preprocessing directive ..." So the language decides choice c) for us.

As as you point out, that choice is not a valid expression.

End of language lawyer mode.

[laserlight]

I incorrectly used the term preprocessor tokens when the standard term is preprocessing tokens.

Aye, but when you want to be a language lawyer, you need to be accurate

Otherwise, you could have just mentioned "greedy matching" instead, and hopefully quzah would have had a better chance of recognising the rule.