Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9406 > unrolled thread

confusion about behavior

Back to article view | Back to comp.lang.c

Contents

  confusion about behavior LJ <djtheshowstopper@gmail.com> - 2011-08-14 11:56 -0700
    Re: confusion about behavior China Blue Tip Wrench <chine.bleu@yahoo.com> - 2011-08-14 12:05 -0700
    Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-14 12:06 -0700
      Re: confusion about behavior Todd Carnes <toddcarnes@gmail.com> - 2011-08-15 01:57 +0000
        Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-14 19:10 -0700
          Re: confusion about behavior Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-15 03:44 +0100
            Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-14 20:27 -0700
        Re: confusion about behavior Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-14 22:52 -0400
        Re: confusion about behavior Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
          Re: confusion about behavior Kenneth Brody <kenbrody@spamcop.net> - 2011-08-15 15:31 -0400
            Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-15 12:36 -0700
            Re: confusion about behavior Seebs <usenet-nospam@seebs.net> - 2011-08-15 20:33 +0000
              Re: confusion about behavior Kenneth Brody <kenbrody@spamcop.net> - 2011-08-16 14:39 -0400
                Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-16 12:27 -0700
                  Re: confusion about behavior Willem <willem@toad.stack.nl> - 2011-08-16 19:47 +0000
        Re: confusion about behavior Barry Schwarz <schwarz45@yahoo.com> - 2011-09-05 04:50 -0700
          [OT] Re: confusion about behavior Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-05 09:07 -0400
          Re: confusion about behavior Kenneth Brody <kenbrody@spamcop.net> - 2011-09-06 12:42 -0400
    Re: confusion about behavior James Kuyper <jameskuyper@verizon.net> - 2011-08-14 15:10 -0400
      Re: confusion about behavior Todd Carnes <toddcarnes@gmail.com> - 2011-08-15 02:04 +0000
        Re: confusion about behavior Keith Thompson <kst-u@mib.org> - 2011-08-14 19:15 -0700
          Re: confusion about behavior Todd Carnes <toddcarnes@gmail.com> - 2011-08-15 02:34 +0000
        Re: confusion about behavior James Kuyper <jameskuyper@verizon.net> - 2011-08-14 22:37 -0400
      Re: confusion about behavior Todd Carnes <toddcarnes@gmail.com> - 2011-08-15 02:26 +0000

Page 2 of 2 — ← Prev page 1 [2]

#9414

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.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9416

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

[toc] | [prev] | [next] | [standalone]

#9417

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

[toc] | [prev] | [next] | [standalone]

#9415

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;
}

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web