> int main()
> {
> int i;
> if(i=foo())
> (void)puts("If this is not seen, it is a compiler BUG!");
>
> return 0;
> }
Wrong. Very, very wrong.
K&R 2nd Edition, page 208 says:
"The type of an assignment expression is that of its left operand,
and the value is the value stored in the left operand after the
assignment has taken place."
The ANSI C standard says in section 6.3.16:
"An assignment expression has the value of the left operand after
the assignment, but is not an lvalue."
This means the expression "i=foo()" evaluates to whatever the value of
'i' is after the assignment; if 'i' is zero, then the expression
evaluates to zero.
K&R 2nd, p. 223, in section A9.4 says:
"In both forms of the if statement, the expression, which must have
arithmetic or pointer type, is evaluated, including all side
effects, and if it compares unequal to 0, the first statement is
executed."
Since page 208 tells us that "i=foo()" has the type "int", which is an
arithmetic type, "i=foo()" is a perfectly legal expression for an if
statement. Its behaviour is well-defined and documented by both K&R
and the ANSI standard. If "i=foo()" evaluates to non-zero, the
statement is executed. If "i=foo()" evaluates to zero, the statement
is not executed. Simple.
Where exactly is this gcc bug you were talking about, then?
> Finished LCLint checking --- 2 code errors found
lint is not and has never been a substitute for the language
definition. I suggest that you obtain and read a copy of K&R or the
ANSI standard before you start declaring language features to be
compiler bugs.
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/