Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!mit-eddie!apollo!arnold
From: arnold@apollo.uucp (Ken Arnold)
Newsgroups: comp.lang.c
Subject: Re: Defining TRUE and FALSE
Message-ID: <3631ff64.ae48@apollo.uucp>
Date: Tue, 21-Jul-87 13:18:00 EDT
Article-I.D.: apollo.3631ff64.ae48
Posted: Tue Jul 21 13:18:00 1987
Date-Received: Thu, 23-Jul-87 03:09:05 EDT
References: <13851@watmath.UUCP> <7460@elsie.UUCP> <13891@watmath.UUCP>
Reply-To: arnold@apollo.UUCP (Ken Arnold)
Organization: Apollo Computer, Chelmsford, MA
Lines: 48
Keywords: true, false, boolean

In article <13891@watmath.UUCP> Eric Giguere writes:
>I think, however, that lint is pretty picky if
>it flags an expression of the form
>
>     i = ( 0 == 0 );
>
>which is perfectly valid if you read the grammar to the language.
>Any decent compiler will simply fold this value into the appropriate
>constant value.

You seem to have missed the whole point of lint.  lint's job is not to
check for syntactic correctness.  Its job is to check for unusual
constructs which *are* syntactically correct, but which are potentially
bugs.  In the normal case, one does not say

	if (1 == 2)

If such a statement occurrs in the code, it is *probably* because
someone mistyped something, or possibly used a #define constant which
they didn't realize was a constant.  Thus, lint isn't being "pretty
picky" -- lint is doing its job.  Generally speaking, it's the C
compiler's job to check for syntax, and lint's job to check for
legal-but-questionable semantics.

The only case where lint will not complain about constants in
conditional context is

	while (1)

since this is a common construct used in place of

	for (;;)

for reasons which escape me personally, but seem obvious to the people
who do it.  (Please don't let's start an argument over this -- it is
as unimportant as the "i++" stuff, and I'm not attacking you personally
if you do this; I'm just insulting your mother :-)

Since it is an absolute C truth that any non-zero value is true, and
any zero value is false, there is no reason whatsoever to be cute and
use such a construct as "0 == 0" to get TRUE, since it is incorrect to
test against TRUE anyway.  Silicon Graphics did (and probably still
does) something like this, and it drove me up a wall and a half, since
it made it impossible to run lint on my code unless I #undef'ed TRUE
and FALSE, and the #define'ed them myself, which was ugly as sin and
twice as expensive (emotionally speaking).

		Ken Arnold