Seebs

On 2010-08-26, Balban <bilgehan.balban@gmail.com> wrote:
> I have this code:

> BUG_ON(value++ == 0);

BUG_ON looks like it may be a macro.

> I expect value to increment and not be equal to zero. In other words,
> it should be a positive integer after increment.

That seems likely.

> I look up the precedence chart and ++ at either post or pre increment
> is higher precedence than == operator.

This is basically irrelevant. Precedence has nothing to do with order
of evaluation.

> I would expect the increment to
> occur regardless of post or pre, before the equality operator is
> evaluated. Is this correct? I still get caught to BUG_ON().

First up: It is quite common for a name like "BUG_ON" to denote a
macro *which evaluates its arguments more than once*. Which means
it may increment value more than once.

Let's look at:
if (value++ == 0) {
printf("got here! value now %d\n", value);
}

What this should do is:

1. Increment value.
2. If value was zero *BEFORE* it was incremented, print
"got here! value now 1\n".

The reason is that "i++" evaluates to the current value of i, but causes i
to be incremented. Note that this doesn't mean the increment happens before
or after anything else -- it just means that you get the value that the
variable had before the increment.

-s
--
Copyright 2010, 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!
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Thomas Richter

Balban wrote:
> Hi,
>
> I have this code:
>
> BUG_ON(value++ == 0);
>
> I expect value to increment and not be equal to zero. In other words,
> it should be a positive integer after increment.
>
> I look up the precedence chart and ++ at either post or pre increment
> is higher precedence than == operator. I would expect the increment to
> occur regardless of post or pre, before the equality operator is
> evaluated. Is this correct? I still get caught to BUG_ON().

This is not a question of operator precedence. postincrement ++ promises
to increment the rvalue after evaluation of the expression, that is,
equality is checked first, then the rvalue is incremented.

Greetings,
Thomas
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Francis Glassborow

On 26/08/2010 17:40, Balban wrote:
> Hi,
>
> I have this code:
>
> BUG_ON(value++ == 0);
>
> I expect value to increment and not be equal to zero. In other words,
> it should be a positive integer after increment.
>
> I look up the precedence chart and ++ at either post or pre increment
> is higher precedence than == operator. I would expect the increment to
> occur regardless of post or pre, before the equality operator is
> evaluated. Is this correct? I still get caught to BUG_ON().

value++ returns the current value of 'value' and then increments the
stored value.

The precedence has no relevance. You need to understand that evaluating
an expression results in a value. In addition the evaluation may
sometimes have a side effect (i.e. changes something or does something).
The increment and decrement operators return a value and have a side
effect of changing the stored value. The pre increment and decrement
operators return the stored value after it has been changed. The post
versions return the value before the change.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Keith Thompson

Balban <bilgehan.balban@gmail.com> writes:
> I have this code:
>
> BUG_ON(value++ == 0);
>
> I expect value to increment and not be equal to zero. In other words,
> it should be a positive integer after increment.
>
> I look up the precedence chart and ++ at either post or pre increment
> is higher precedence than == operator. I would expect the increment to
> occur regardless of post or pre, before the equality operator is
> evaluated. Is this correct? I still get caught to BUG_ON().

Precedence does not dictate evaluation order, nor does it change
the values yielded by an operator for a given set of operands.

Postfix ++ yields the value that the object had *before* the
increment occurred (and, as a side effect, modifies the value of
the object). So if the previous value of ``value'' was 0 (that's
implied by your description, but it would have been good to say so),
then the expression

(value++ == 0)

will yield true (1) and, as a side effect, will cause the value 1
to be stored in ``value''. It's not defined, and in this case it
doesn't matter, whether the side effect occurs before or after the
"==" operator is evaluated; the left operand that "==" sees is the
previous value of ``value'', whether the store has occurred yet
or not.

You also haven't shown us the definition of BUG_ON. I presume it's
a macro. If its definition doesn't properly parenthesize references
to its argument, or if it evaluates its argument more than once
(or less than once), then you could have additonal problems.
It's usually not a good idea to use expressions with side effects
as macro arguments. For example, if you were using the standard
assert() macro, the side effect would or would not take place
depending on whether you've #define'd NDEBUG.

I suspect you want

BUG_ON(++value == 0);

which tests the value of ``value'' (this would be easier to talk
about if you'd chosen a different name, even ``x'') *after* its
been incremented.

If your expectations were correct, there would be no difference
between prefix and postfix ++ operators, and no point in having
them both in the language. That should be a clue that you're
missing something.

--
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"
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

Kenneth Brody

On 8/26/2010 5:20 PM, Thomas Richter wrote:
> Balban wrote:
>> Hi,
>>
>> I have this code:
>>
>> BUG_ON(value++ == 0);
[...]
>
> This is not a question of operator precedence. postincrement ++ promises to
> increment the rvalue after evaluation of the expression, that is,
> equality is checked first, then the rvalue is incremented.

Incorrect. When the increment takes place is irrelevant, and can take place
any time between the previous and following sequence points.

However, what it does mean, is that whatever value was in "value" before the
increment took place is what gets compared to zero. It would be perfectly
legal to increment "value" first, and then compare "value-1" to zero. (Or to
compare the incremented value to 1.)

And, as others have pointed out, BUG_ON() appears to be the name of a macro,
and without seeing how it is implemented, it's possible that it refers to
its parameter multiple times and/or without parenthesizing it, which can
cause "bad things" to happen when passed something like the above.

--
Kenneth Brody
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.