TRUE and FALSE

[Sean Legassick]

In article <2342 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
=In <1990Aug29.153917.28110 at warwick.ac.uk> asrap at warwick.ac.uk (Sean
=Legassick) explains why he might want to use enum {false, true} for
=booleans in C and continues:
=
=>I would be interested in anyone who thinks an int declaration of
=>a boolean variable is clearer.
=
=It depends.  Try this:
=
[code ommited which demonstrates comparison with true will not work]
=
=Since isdigit() is not guaranteed to return 0 or 1, the value of
=got_digit could be something else (e.g. 4).  Then, even when got_digit
=is true by C conventions (nonzero), it isn't necessarily equal to its
=enumeration value "true".
=
=No matter what you do, you cannot in C get around this:
=
=     Although the result of a boolean condition is always 0 or 1, all
=     nonzero values are considered to be true in a boolean context.
=     All mechanisms that try to represent this fact using only two
=     values (e.g. TRUE and FALSE, or enum {false, true}) are likely to
=     lead to bad code that looks good.

	But as has frequently been mentioned in this thread, comparison
to any #defined TRUE and FALSE, and enum { false, true } or even just
0 and 1 cannot be guaranteed to work. Therefore I use a 'bool' type but
I NEVER USE FALSE OR TRUE IN COMPARISONS. In the code you quote I would
say:
	bool foo;
	foo = isdigit(bar);
	if (foo) ...

	Guaranteed to work, and blatantly obvious what it does. There's
nothing that says if you use bool types you have to compare to TRUE or FALSE,
you don't do it without them, so why do it with them?

--------------------------------------------------------------------------
Sean Legassick,       cuuee at uk.ac.warwick.cu  "Improbability factor of one
Computing Services    asrap at uk.ac.warwick.cu    to one. We have normality.
University of Warwick      	 	         Anything you still can't
            (the walking C obfuscator!)	 	  handle is your own problem."