Messages in this thread | | | From | Andreas Moroder <> | Subject | AW: fork() Problem | Date | Thu, 6 May 1999 08:36:50 +0100 |
| |
It's really not a bug, its only one of thoes things in C that can make you get crazy. You should never use this "feature" of C, because if you look at the source after few weeks you are not shure if you did want it to behave this way or if you did a mistake forgetting the second =
-----Ursprüngliche Nachricht----- Von: Matt Stocum Gesendet am: 06.05.1999 03:56 An: linux-kernel@vger.rutgers.edu Betreff: Re: fork() Problem
> > The problem is that if anybody writes code like this, they should be > terminated with extreme prejudice. This is using a gcc compiler bug as > a feature. > > #include <stdio.h> > > int foo() > { > return 0; > } > > int main() > { > int i; > if(i=foo()) > (void)puts("If this is not seen, it is a compiler BUG!"); > > return 0; > } >
Actually I'm fairly certain it's not a bug but the way C is designed. When you do an assignment ie i = foo() that assignment returns the value of foo(). This way you can do x = y = i = foo(). That is a 100% legal statement in C. Using if(i=foo()) is legal because of this. The expression i=foo() returns the value of foo() whatever that might be. In the case of your test program it will be 0 and the if statement will evaluate to false and you won't see the message. It's not a bug though.
-matt
- 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/
- 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/
| |