### Question 9.2

Isn't #defining `TRUE` to be 1 dangerous, since any nonzero value is considered ``true'' in C? What if a built-in logical or relational operator ``returns'' something other than 1?

It is true (sic) that any nonzero value is considered true in C, but this applies only ``on input'', i.e. where a Boolean value is expected. When a Boolean value is generated by a built-in operator, it is guaranteed to be 1 or 0. Therefore, the test

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

would work as expected (as long as `TRUE` is 1), but it is obviously silly. In general, explicit tests against `TRUE` and `FALSE` are inappropriate, because some library functions (notably `isupper`, `isalpha`, etc.) return, on success, a nonzero value which is not necessarily 1. (Besides, if you believe that ```if((a == b) == TRUE)`'' is an improvement over ```if(a == b)`'', why stop there? Why not use ```if(((a == b) == TRUE) == TRUE)`''?) A good rule of thumb is to use `TRUE` and `FALSE` (or the like) only for assignment to a Boolean variable or function parameter, or as the return value from a Boolean function, but never in a comparison.

The preprocessor macros `TRUE` and `FALSE` (and, of course, `NULL`) are used for code readability, not because the underlying values might ever change. (See also questions 5.3 and 5.10.)

On the other hand, Boolean values and definitions can evidently be confusing, and some programmers feel that `TRUE` and `FALSE` macros only compound the confusion. (See also question 5.9.)

References: K&R1 Sec. 2.6 p. 39, Sec. 2.7 p. 41
K&R2 Sec. 2.6 p. 42, Sec. 2.7 p. 44, Sec. A7.4.7 p. 204, Sec. A7.9 p. 206
ANSI Sec. 3.3.3.3, Sec. 3.3.8, Sec. 3.3.9, Sec. 3.3.13, Sec. 3.3.14, Sec. 3.3.15, Sec. 3.6.4.1, Sec. 3.6.5
ISO Sec. 6.3.3.3, Sec. 6.3.8, Sec. 6.3.9, Sec. 6.3.13, Sec. 6.3.14, Sec. 6.3.15, Sec. 6.6.4.1, Sec. 6.6.5
H&S Sec. 7.5.4 pp. 196-7, Sec. 7.6.4 pp. 207-8, Sec. 7.6.5 pp. 208-9, Sec. 7.7 pp. 217-8, Sec. 7.8 pp. 218-9, Sec. 8.5 pp. 238-9, Sec. 8.6 pp. 241-4
``What the Tortoise Said to Achilles''

Read sequentially: prev next up top

This page by Steve Summit // Copyright 1995 // mail feedback