Messages in this thread | | | From | Steve VanDevender <> | Date | Wed, 5 May 1999 14:13:28 -0700 (PDT) | Subject | Re: fork() Problem? |
| |
Richard B. Johnson writes: > > To quote the C Reference Manual (which is also the ANSI C > > Standard document) in _The C Programming Language, Second > > Edition_ by Kernighan and Ritchie: > > > > A7.17 Assignment Expressions > > > > There are several assignment operators; all group right-to-left. > > > > assignment-expression: > > conditional-expression > > unary-expression assignment-operator assignment-expression > > > > assignment-operator: one of > > = *= /= %= += -= <<= >>= &= ^= |= > > > > All require an lvalue as left operand, and the lvalue must be > > modifiable: it must not be an array, and must not have an > > incomplete type, or be a function. Also, its type must not be > > qualified with const; if it is a structure or union, it must not > > have any member or recursivly, submember qualified with const. > > > > 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. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > So an assignment expression does have a value, and consequently > > can be legally used as a conditional expression in if, while, do, > > or for statements. > > > > In the future, Richard, please trouble yourself to do some real > > research rather than treating your personal opinions as > > incontrovertible facts. > > No damnit! Look at the rules. Don't modify them to suit your > opinions.
I'm reading the ANSI C standard. The language in the standard is quite clear. This is not my personal opinion; it is my experience with how C actually works.
> #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; > } > > Now, look what Lint has to say about this. The purpose of Lint > is to check rules. It has no opinion. It just checks rules.
lint is not a compiler. What it calls an error is stylistic, not semantic. lint will complain about a lot of things that are legal C but stylistically undesirable. Look:
---dumbass.c--- #include <stdio.h>
int foo() { return 0; }
int main() #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!"); else (void)puts("Richard Johnson is a dumbass");
return 0; } ---dumbass.c---
Digital UNIX 4.0E cc $ cc dumbass.c Digital UNIX 4.0E cc $ ./a.out Richard Johnson is a dumbass
Solaris 2.6 Sun C 4.0 $ cc dumbass.c Solaris 2.6 Sun C 4.0 $ ./a.out Richard Johnson is a dumbass
Linux 2.2.7 gcc 2.7.2.3 $ cc dumbass.c Linux 2.2.7 gcc 2.7.2.3 $ ./a.out Richard Johnson is a dumbass
The two non-gcc compilers agree happily with both gcc and the ANSI C standard as quoted above.
You seem to be the one who won't let the facts get in the way of your opinions. In the future I suggest that you be a little more careful about presenting your untested opinions as facts, especially when it is so easy to prove you wrong.
- 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/
| |