confusion about behavior

[LJ]

int a = 2;
int b = 3;
c = a+++b;
What will be the value of c??
Shouldn't it be undefined depending upon the interpretation??

 

[Keith Thompson]

int a = 2;
int b = 3;
c = a+++b;
What will be the value of c??
Shouldn't it be undefined depending upon the interpretation??

In a professional environment, the result will be "go back and fix
the code, then we'll look at it".

The assignment is equivalent to

c = a++ + b;

due to the "maximal munch" rule (the same rule that makes "a+++++b"
a syntax error rather than "a++ + ++b"). The code is badly formatted
and difficult to read, but there is no ambiguity.

I'll assume that's enough to tell you what the code does. If not,
feel free to ask.

 

[James Kuyper]

int a = 2;
int b = 3;
c = a+++b;
What will be the value of c??
Shouldn't it be undefined depending upon the interpretation??

The C standard mandates what's called the "maximal munch" rule; "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." (6.4p4)

Therefore, there's only one permitted way of parsing the third statement:

c = a++ + b;

That's equivalent to the following statement, where I've inserted some
unnecessary parenthesis to clarify the order of operations:

c = ((a++) + b);

Assuming that c has an arithmetic type, the behavior of that statement
is well-defined: 'a' ends up with a value of 3, and c ends up with a
value of 5 (converted, if necessary, to whatever the type of c happens
to be).

 

[Todd Carnes]

In a professional environment, the result will be "go back and fix the
code, then we'll look at it".

The assignment is equivalent to

c = a++ + b;

due to the "maximal munch" rule (the same rule that makes "a+++++b" a
syntax error rather than "a++ + ++b"). The code is badly formatted and
difficult to read, but there is no ambiguity.

I'll assume that's enough to tell you what the code does. If not, feel
free to ask.

So, you're saying that it will first increment a by 1, then add the
result to b?

What prevents it from being interpreted as a + ++b? Nevermind, I just
realized that you get the same result either way.

Todd

 

[Todd Carnes]

The C standard mandates what's called the "maximal munch" rule; "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." (6.4p4)

Therefore, there's only one permitted way of parsing the third
statement:

c = a++ + b;

That's equivalent to the following statement, where I've inserted some
unnecessary parenthesis to clarify the order of operations:

c = ((a++) + b);

Assuming that c has an arithmetic type, the behavior of that statement
is well-defined: 'a' ends up with a value of 3, and c ends up with a
value of 5 (converted, if necessary, to whatever the type of c happens
to be).

So, c would actually be equal to 6.

c = ((a++) + b)
c = ((2++) + 3)
c = (3 + 3)
c = 6

I never heard of the "maximal munch" thing. Thanks for the explanation.

Todd

 

[Keith Thompson]

So, you're saying that it will first increment a by 1, then add the
result to b?

No, it's a post-increment. The value of the expression `++a' is the
value of a *before* the increment, 2 (and, as a side effect, it sets a
to 3).

What prevents it from being interpreted as a + ++b? Nevermind, I just
realized that you get the same result either way.

The "maximal munch" rule is what prevents it from being interpreted
as ``a + ++b'' And no, it wouldn't give you the same result; ``++b''
is a pre-increment, which means that result is the value of b *after*
incrementing it (4), which would change the value assigned to c.
It would also change which of a or b is affected by the increment.

 

[Keith Thompson]

So, c would actually be equal to 6.

c = ((a++) + b)
c = ((2++) + 3)
c = (3 + 3)
c = 6

No.

First of all, (2++) is not a valid expression. The "++" operator can
only be applied to an lvalue (an expression that designates an object),
not to a constant. That's because it has the side effect of modifying
the object.

Second, as I explained elsethread, it's a post-increment; the expression
a++ yields 2, not 3.

Finally, wouldn't it have been easier to try it yourself and see what it
does? (Of course that's not definitive in the case of programs with
unspecified or undefined behavior, but it's worth trying it.)

 

[Todd Carnes]

The C standard mandates what's called the "maximal munch" rule; "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." (6.4p4)

Therefore, there's only one permitted way of parsing the third
statement:

c = a++ + b;

That's equivalent to the following statement, where I've inserted some
unnecessary parenthesis to clarify the order of operations:

c = ((a++) + b);

Assuming that c has an arithmetic type, the behavior of that statement
is well-defined: 'a' ends up with a value of 3, and c ends up with a
value of 5 (converted, if necessary, to whatever the type of c happens
to be).

Ok, I ran the code below and got 5, just like you said it would be. Keith
already explained why. I got the pre- and post- increment thing wrong.

Todd

#include <stdio.h>

int main(int argc, char **argv)
{
int a = 2;
int b = 3;
int c;

c = a+++b;

printf("c = %i", c);
return 0;
}

 

[Todd Carnes]

On Sun, 14 Aug 2011 19:15:26 -0700, Keith Thompson wrote:

[snip]

First of all, (2++) is not a valid expression.

I know that it wasn't a valid expression in C. It wasn't supposed to be.
I wasn't writing code. I was doing the math... i.e. I was trying to show
my thinking that led to an answer of 6 by substituting the values of a
and b into the equation and working out the math.

I posted that, before I saw your reply regarding post & pre increments.
Thanks for the explanation. I get it now.

Finally, wouldn't it have been easier to try it yourself
and see what it does?

I just did that. However, that only verifies that James was correct about
the result being 5. Running the code didn't explain *why* it was 5. You
and James did that.

Todd

 

[James Kuyper]

So, c would actually be equal to 6.

c = ((a++) + b)
c = ((2++) + 3)
c = (3 + 3)
c = 6

c = ((a++) + b); is equivalent to the following:

{
int temp = a;
a = a + 1;
c = (temp + b);
}

When you fill in the numbers, you'll get c==5.

 

[Ben Bacarisse]

No, it's a post-increment. The value of the expression `++a' is the
value of a *before* the increment, 2 (and, as a side effect, it sets a
to 3).

Typo: you meant `a++'. Of course it would happen in a post about the
different between pre- and post-increment!

<snip pre-increment example>

 

[Eric Sosman]

So, you're saying that it will first increment a by 1, then add the
result to b?

No. `a++' is not the same as `++a'. Your textbook or other
reference is sure to explain the difference.

What prevents it from being interpreted as a + ++b? Nevermind, I just
realized that you get the same result either way.

No, again. With the given initial conditions, `a++ + b'
yields 5, while `a + ++b' yields 6. Go back to the book!

 

[Keith Thompson]

Typo: you meant `a++'. Of course it would happen in a post about the
different between pre- and post-increment!

<snip pre-increment example>

D'oh++!

 

[Seebs]

What prevents it from being interpreted as a + ++b?

The "maximal munch" rule.

"++" is a larger token than "+". Therefore, if you see two +, it *MUST*
be ++, and *CANNOT* be "+", even if that later results in a syntax error.

So:
a+++b
a => start a token
+ => there is no token starting "a+", so "a" was a token, and we now have "+"
+ => there is a token starting "++", and that's complete
+ => start a new token, consisting of "+", keep looking...
b => "+b" can't be a token, so the "+" becomes a token.

(Then we hit ";" and because "b;" can't be a token, "b" is a token and ";"
is a token.)

Basically, in order for it to be "+ ++b", the compiler would have to look
at "++" and decide to split off the first part of it, and it can't.

-s

 

[Keith Thompson]

On 8/15/2011 12:28 AM, Seebs wrote:
[...]

The "maximal munch" rule.

"++" is a larger token than "+". Therefore, if you see two +, it *MUST*
be ++, and *CANNOT* be "+", even if that later results in a syntax error.

So:
a+++b
a => start a token
+ => there is no token starting "a+", so "a" was a token, and we now have "+"
+ => there is a token starting "++", and that's complete
+ => start a new token, consisting of "+", keep looking...

Nit:

The second '+' shouldn't really say "and that's complete".

The third '+' should really be "there is no '+++' token, nor does any token
start with it, so _now_ '++' is now complete, and we start a new token,
consisting of '+', keep looking".

Counter-nit:

The second '+' could say "The *only* token starting with ++ is ++
itself; therefore, that's complete".

The lexical scanner could realize that "++" is the complete token either
when it sees the second '+', or when it sees the third one. The effect
is exactly the same either way.

 

[Seebs]

The second '+' shouldn't really say "and that's complete".

The third '+' should really be "there is no '+++' token, nor does any token
start with it, so _now_ '++' is now complete, and we start a new token,
consisting of '+', keep looking".

I'm not sure of this. I think a tokenizer can reasonably say "I know that
this is a complete token, and that there is no longer token which has this
as a prefix", and punt.

-s

 

[Keith Thompson]

True. (As also pointed out my Keith Thompson.)

But, to nit^3, the point on "and that's complete" should include that part.
Otherwise, one might argue "but the single '+' is also a complete token",
despite it not being the longest possible complete token.

Seebs already covered your nit^3: "and that there is no longer token
which has this as a prefix".

 

[Willem]

Keith Thompson wrote:
)> On 8/15/2011 4:33 PM, Seebs wrote:
)>>> The second '+' shouldn't really say "and that's complete".
)>>>
)>>> The third '+' should really be "there is no '+++' token, nor does any token
)>>> start with it, so _now_ '++' is now complete, and we start a new token,
)>>> consisting of '+', keep looking".
)>>
)>> I'm not sure of this. I think a tokenizer can reasonably say "I know that
)>> this is a complete token, and that there is no longer token which has this
)>> as a prefix", and punt.
)>
)> True. (As also pointed out my Keith Thompson.)
)>
)> But, to nit^3, the point on "and that's complete" should include that part.
^^^^^^^^^^^^^^^^^^^^^^^^^
)> Otherwise, one might argue "but the single '+' is also a complete token",
)> despite it not being the longest possible complete token.
)
) Seebs already covered your nit^3: "and that there is no longer token
) which has this as a prefix".

He knew that already. He just pointed out that the second half of the
condition was necessary. I do not agree that that was a nit to pick,
though, as it was not actually in error in the first place. More a NB.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Barry Schwarz]

So, you're saying that it will first increment a by 1, then add the
result to b?

No one said a would b e incremented first. The expression a++ will
evaluate to 2. That is what will be added to b, producing a sum of
5. As a side effect of the ++ operatore, a will be incremented
sometime before the next sequence point, which happens to be the
semicolon at the end of the statement.

What prevents it from being interpreted as a + ++b? Nevermind, I just

The maximum munch rule forces the expression to be parsed as a++ + b.

realized that you get the same result either way.

No you don't. In the expression a + (++b), ++b evaluates to 4 which
will be added to a producing a sum of 6.

 

[Eric Sosman]

On 9/5/2011 7:50 AM, Barry Schwarz wrote:
^^^^^^^^

On Aug 14, 6:57 pm, Todd Carnes<[email protected]> wrote:

^^^^^^

Let's do
The Time Warp
Aga-a-a-in!