Definition of boolean type

[Jim Shankland]

In article <15906 at mimsy.UUCP> chris at 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 at ernie.berkeley.edu

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