Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.lang.c
Subject: Re: Definition of boolean type
Message-ID: <27989@ucbvax.BERKELEY.EDU>
Date: 12 Feb 89 00:28:29 GMT
References: <10@dbase.UUCP> <9609@smoke.BRL.MIL> <3645@arcturus> <15906@mimsy.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU.UUCP (Jim Shankland)
Organization: University of California, Berkeley
Lines: 30

In article <15906@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Perhaps the biggest problem with boolean types, and definitions for
>`TRUE' and `FALSE' ... is exemplified by ...:
>
>	#define FALSE 0
>	#define TRUE ~FALSE
>	...
>	/* these macros return TRUE when the queue is empty/full/... */
>	#define ISEMPTY(eq) ((eq)->head.foo == (eq)->tail.foo)
>
>The code then read
>
>		if (ESEMPTY(eq) == TRUE) bar();

Bleck.  But this is no more an argument against boolean types than an
incompetent surgeon is an argument against surgery.  First, TRUE ought
to be defined to be the same value returned by relops:  1.  Second,
as Mark Brader has pointed out, "if (<bool-val> == TRUE)" is an abomination.
Do you say, "If the weather's nice tomorrow is true, I'll have a picnic"?
Or "If the queue is empty is true, I'd better call bar()"?

I agree with Karl Heuer:  C would have benefited from a built-in boolean
type.  As is, conscientious programmers will avoid type punning between
values that are conceptually boolean with those that are conceptually
integers (though as far as C is concerned, of course they're both integers.)

Jim Shankland
jas@ernie.berkeley.edu

"I've been walking in a river all my life, and now my feet are wet"