Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!mit-eddie!ll-xn!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Defining TRUE and FALSE
Message-ID: <23253@sun.uucp>
Date: Sun, 12-Jul-87 05:31:09 EDT
Article-I.D.: sun.23253
Posted: Sun Jul 12 05:31:09 1987
Date-Received: Mon, 13-Jul-87 00:47:57 EDT
References: <13851@watmath.UUCP> <7460@elsie.UUCP> <13891@watmath.UUCP>
Sender: news@sun.uucp
Lines: 61
Keywords: true, false, boolean

> There have been some interesting comments, all valid.  Yes, in a 
> proper implementation
> 
>      #define TRUE 1
>      #define FALSE 0
> 
> should work properly.  The solution I offered was one that should
> guarantee portability.

Nope.  If you assume that the implementation can get the definition
of the "==" operator wrong to the extent that "0 == 0" does not
evaluate to 1, and that to be safe you have to define TRUE as "0 ==
0", you should also assume that it can get the definition of the "+"
operator wrong so that "1 + 1" doesn't evaluate to 2.

The definition of the "==" operator is pretty clearly spelled out in
all descriptions of C; anybody who gets *that* wrong is capable of
just about any screwup.  Unless the quality of C implementations out
there is *so* dismal that C cannot be taken seriously as a portable
language for implementing software (in which case, you shouldn't
implementing software in C if you intend to port it), writing code
that "defends" against the possibility that an implementation of the
language is fundamentally flawed is silly (*and* does not "guarantee
portability" unless you defend against practically every screwup that
can be imagined), nor does assuming that the implementation is *not*
fundamentally flawed run the risk of unportability as you seem to be
implying here.

> 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.

It's syntactically valid, but so what?  That's not the point.  "lint"
complains about this if it is asked to "Apply a number of heuristic
tests to attempt to intuit bugs, improve style, and reduce waste."
The key words here are "heuristic" and "intuit".  It is trying to
detect code that is syntactically valid, and perhaps even
semantically valid, but possibly wrong anyway.  This test will pick
up errors such as writing

	if (datum & MASK == VALUE)

rather than

	if ((datum & MASK) == VALUE)

to test whether a subfield of "datum" is equal to a particular value.
(This could be considered an argument in favor of bitfields; with
bitfields, you can directly express what you mean here, and not fact
the possibility of getting the test wrong.  You can't use bitfields
in all cases - if the format of "datum" is externally imposed, you
will probably need the mask, since the order in which bit fields are
placed within structure is implementation-dependent.)
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com