TRUE and FALSE

Chris Torek chris at mimsy.umd.edu
Thu Aug 30 23:08:56 AEST 1990


>>In <514 at demott.COM> kdq at demott.COM (Kevin D. Quitt) writes:
>>>TRUE and FALSE are used for assignment purposes only.  It makes
>>>the intent of the code more obvious.

>In article <2316 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com
(the much-misunderstood Rahul Dhesi) writes:
[yes, you have seen it before, but this time read it with a `sarcastic
face' in mind]
>>When I find somebody who really, really, really wants to define TRUE
>>and FALSE, even somebody who uses them for assignment only, I recommend
>>the following defines instead:
>>
>>     #define ZERO   0
>>     #define ONE    1
>>
>>These are so much more clear than TRUE and FALSE, and if you use
>>them in a test, you know exactly what you're testing!

In article <3835 at sactoh0.SAC.CA.US> jak at sactoh0.SAC.CA.US (Jay A. Konigsberg)
misses the scarcasm:
>Pish-posh! TRUE and FALSE are much clearer. Kevin is correct when
>he says TRUE and FALSE are used for assignment purposes only. The
>resulting values are then easly checked in standard C syntax making
>the code more self-documentating.
>
>Personally though, I like the following:
>
>#define TRUE -1

Since this is all going around again (already!), it is probably time
for a small addition to the FAQ list:

Q: How about Booleans in C?  For instance:

	typedef int bool;
	#define FALSE 0
	#define TRUE 1

A: Some people believe this adds clarity.  Beware, however:

	typedef enum { true, false } bool;	/* bug */

	bool result;
	result = a == b;

   Surprise, this sets `result' to `true' if a!=b, and to `false'
   if a==b.  Or consider

	#define FALSE 0
	#define TRUE -1

	if ((a == b) == TRUE) ...

   This `if' test never runs.  Or:

	if (x) ...
   vs	if (x == TRUE) ...
   vs	if (x != FALSE) ...

   The middle line does something different from the first and last
   lines.

Q: What about

	#define FALSE (1==0)
	#define TRUE (1==1)

   Since C defines the RESULT of all boolean operators as 0-for-false
   and 1-for-true (but does not make such a requirement on the TEST
   value in if, while, etc.), this is needless make-work for the compiler.
   Some people have suggested that this is useful with broken compilers
   (where `true' results produce the value -1, for instance), but if
   the compiler gets something this basic wrong, how can you trust it
   to produce correct code for anything even moderately complicated?

   These defines still suffer from the problem that `x==TRUE' means
   something different from `x!=FALSE'.

   As a final note, the `best' choice of storage type for a boolean
   is not necessarily `int' (in some situations a bit array would be
   best, although C does not provide such directly).  If you use an
   enumerated type, the storage type is up to the compiler; however,
   the compiler is then free to warn about
   	bool x = a == b;
   since the result of `a==b' is an `int' and not an enumeration
   member.  (The compiler must accept the expression; it may only
   generate a warning at most.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list