Asp Forum - confusion about behavior

LJ

8/14/2011 6:56:00 PM

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

23 Answers

China Blue Veins

8/14/2011 7:06:00 PM

In article <cda0e503-482a-4075-b3fa-af3013819716@l11g2000prh.googlegroups.com>,
LJ <djtheshowstopper@gmail.com> wrote:

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

- Doctor, doctor! It hurts when I do this!
- Then don't that anymore.

--
I remember finding out about you, | How to loosen bolts with a hammer.
Everyday my mind is all around you,| I'm whoever you want me to be.
Looking out from my lonely room | Annoying Usenet one post at a time.
Day after day. | At least I can stay in character.

Keith Thompson

8/14/2011 7:06:00 PM

LJ <djtheshowstopper@gmail.com> writes:
> 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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper

8/14/2011 7:11:00 PM

On 08/14/2011 02:56 PM, LJ wrote:
> 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).
--
James Kuyper

Todd Carnes

8/15/2011 1:57:00 AM

On Sun, 14 Aug 2011 12:06:19 -0700, Keith Thompson wrote:

> LJ <djtheshowstopper@gmail.com> writes:
>> 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.

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

8/15/2011 2:05:00 AM

On Sun, 14 Aug 2011 15:10:48 -0400, James Kuyper wrote:

> On 08/14/2011 02:56 PM, LJ wrote:
>> 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).

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

8/15/2011 2:11:00 AM

Todd Carnes <toddcarnes@gmail.com> writes:
> On Sun, 14 Aug 2011 12:06:19 -0700, Keith Thompson wrote:
>> LJ <djtheshowstopper@gmail.com> writes:
>>> 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.
>
> 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 (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson

8/15/2011 2:15:00 AM

Todd Carnes <toddcarnes@gmail.com> writes:
> On Sun, 14 Aug 2011 15:10:48 -0400, James Kuyper wrote:
>> On 08/14/2011 02:56 PM, LJ wrote:
>>> 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).
>
> 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.)

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

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Todd Carnes

8/15/2011 2:27:00 AM

On Sun, 14 Aug 2011 15:10:48 -0400, James Kuyper wrote:

> On 08/14/2011 02:56 PM, LJ wrote:
>> 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).

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

8/15/2011 2:34:00 AM

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

8/15/2011 2:38:00 AM

On 08/14/2011 10:04 PM, Todd Carnes wrote:
> On Sun, 14 Aug 2011 15:10:48 -0400, James Kuyper wrote:
>
>> On 08/14/2011 02:56 PM, LJ wrote:
>>> 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??
....
>> 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

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.

--
James Kuyper

comp.lang.c

confusion about behavior

LJ

China Blue Veins

Keith Thompson

James Kuyper

Todd Carnes

Todd Carnes

Keith Thompson

Keith Thompson

Todd Carnes

Todd Carnes

James Kuyper

x Login to ForumsZone