He isn't, he quoted the ANSI C standard. Its the same rule that allows you
to do:
x = y = z;
If Richard were correct then x would be TRUE or FALSE depending on the
assignment of y = z working, i.e. TRUE. BTW this is almost what PL/1 does
with the same statement !
> 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.
Amen brother.
> > 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:
In some circumstances Lint has to be ignored. It is the sign of a skilled
developer who knows when Lint is talking bollocks, as a result of its
fevered imagination. The use of:
if (a = b)
is often a problem with newbies as almost every other language uses this
as the format of an equality test. Many people on learning C forget and
use this instead. If this were not such a common problem then both GCC and
Lint probably wouldn't flag it up. The problem is that when used by
someone who knows what they are talking about, they have to put up with
this newbie trap warning.
> 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
Windows NT 4.0, Visual C++ 5.0
> The two non-gcc compilers agree happily with both gcc and the
> ANSI C standard as quoted above.
Even Microsoft agrees with you. The test program was different but it
was testing the same rule.
> 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.
I suggest this conversation should be moved to comp.lang.c.
Jonathan
-
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/