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 1 of 2  [1] 2  Next page →

#9406 — confusion about behavior

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

[toc] | [next] | [standalone]

#9407

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.

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

#9408

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.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]

#9411

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

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

#9413

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.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]

#9418

Keith Thompson <kst-u@mib.org> writes:
<snip>
> 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>
-- 
Ben.

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

#9420

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
> <snip>
>> 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>

D'oh++!

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

#9419

On 8/14/2011 9:57 PM, Todd Carnes wrote:
> 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.  `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!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#9421

On 2011-08-15, Todd Carnes <toddcarnes@gmail.com> wrote:
> On Sun, 14 Aug 2011 12:06:19 -0700, Keith Thompson wrote:
>> 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.

> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#9448

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".

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


-- 
Kenneth Brody

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

#9449

Kenneth Brody <kenbrody@spamcop.net> writes:
> 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.

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

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

#9452

On 2011-08-15, Kenneth Brody <kenbrody@spamcop.net> 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.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#9487

On 8/15/2011 4:33 PM, Seebs wrote:
> On 2011-08-15, Kenneth Brody<kenbrody@spamcop.net>  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.

-- 
Kenneth Brody

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

#9490

Kenneth Brody <kenbrody@spamcop.net> writes:
> On 8/15/2011 4:33 PM, Seebs wrote:
>> On 2011-08-15, Kenneth Brody<kenbrody@spamcop.net>  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".

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

#9491

Keith Thompson wrote:
) Kenneth Brody <kenbrody@spamcop.net> writes:
)> On 8/15/2011 4:33 PM, Seebs wrote:
)>> On 2011-08-15, Kenneth Brody<kenbrody@spamcop.net>  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

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

#9950

On Aug 14, 6:57 pm, Todd Carnes <toddcar...@gmail.com> wrote:
> On Sun, 14 Aug 2011 12:06:19 -0700, Keith Thompson wrote:
> > LJ <djtheshowstop...@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 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.


>
> Todd- Hide quoted text -
>
> - Show quoted text -

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

#9951 — [OT] Re: confusion about behavior

On 9/5/2011 7:50 AM, Barry Schwarz wrote:
    ^^^^^^^^
> On Aug 14, 6:57 pm, Todd Carnes<toddcar...@gmail.com>  wrote:
      ^^^^^^

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

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#9965

On 9/5/2011 7:50 AM, Barry Schwarz wrote:
> On Aug 14, 6:57 pm, Todd Carnes<toddcar...@gmail.com>  wrote:
>> On Sun, 14 Aug 2011 12:06:19 -0700, Keith Thompson wrote:
>>> LJ<djtheshowstop...@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??
[... "maximal munch" requires it to be equivalent to "c = a++ + b"; ...]
>> 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.

Not to mention the fact that b will be incremented rather than a.

-- 
Kenneth Brody

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

#9409

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

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

#9412

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web