Messages in this thread | | | Date | Thu, 06 May 1999 02:47:07 +0000 | From | Tom Eastep <> | Subject | Re: fork() Problem? |
| |
"Richard B. Johnson" wrote: > > On 5 May 1999, Nat Lanza wrote: > > > "Richard B. Johnson" <root@chaos.analogic.com> writes: > > > > > 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. > > > > No it does not. It means, exactly what it says. It says that the > type is that of the left operand (promotion rules) and the value > is the value stored in the left operand after the assignment has > taken place. It says nothing more. > > > 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. > > > > No. It does not say that at all. > > > 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. > > Even 'gcc' knows that the operation is incorrect, but you have to > turn on -Wall.
gcc (plus lint and many other compilers) give this warning because it's too easy to write:
if ( a = b )
when what you wanted was
if ( a == b )
It doesn't mean that the former is wrong -- it just means that the second form is what the programmer usually wanted.
It's particularly easy to make this mistake if (as I do) you code in both C and an ALGOL based language. In ALGOL, the C construct:
if ( a = b )
is coded as
IF A := B THEN
while
if ( a == b )
is written as
IF A = B THEN
In other words, in C "=" means assignment while in ALGOL "=" means equality. As you mentioned in an earlier post, lint is silent if you write:
if ((a = b))
thus signifying that you really wanted
if ( a = b )
and not
if ( a == b )
-Tom -- Tom Eastep Compaq Computer Corporation Enterprise Computing Group Tandem Division tom.eastep@compaq.com
- 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/
| |