lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.054 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site