Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!warwick!asrap
From: asrap@warwick.ac.uk (Sean Legassick)
Newsgroups: comp.lang.c
Subject: Re: TRUE and FALSE
Message-ID: <1990Aug31.121948.9116@warwick.ac.uk>
Date: 31 Aug 90 12:19:48 GMT
References: <2316@cirrusl.UUCP> <1990Aug29.153917.28110@warwick.ac.uk> <2342@cirrusl.UUCP>
Sender: news@warwick.ac.uk (Network news)
Organization: University of Warwick, UK
Lines: 43

In article <2342@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
=In <1990Aug29.153917.28110@warwick.ac.uk> asrap@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@uk.ac.warwick.cu  "Improbability factor of one
Computing Services    asrap@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."