Path: utzoo!attcan!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.JUNET (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: Definition of boolean type
Message-ID: <10132@socslgw.csl.sony.JUNET>
Date: 14 Feb 89 03:47:00 GMT
References: <10@dbase.UUCP> <9609@smoke.BRL.MIL> <3645@arcturus> <15906@mimsy.UUCP>
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan.
Lines: 24

In article <15906@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:

> Perhaps the biggest problem with boolean types, and definitions for
> `TRUE' and `FALSE' (or True and False or true and false or . . .)

> 	#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)
> 	...
> 	if (ESEMPTY(eq) == TRUE) bar();

> It is left as an exercise to the reader to determine why this test
> will never call function bar().

A boolean operator would make it work correctly:

	#define TRUE !FALSE

Of course, TRUE and FALSE *should* be used only as the right-hand-sides
of assignments, not as operands for a comparison.  However, it is not
correct to say that the biggest problem with <x> is that some programmer
codes a bug in which he forgets to use <x>'s operators.