TRUE and FALSE

M.T.Russell mtr at ukc.ac.uk
Tue Sep 4 23:08:38 AEST 1990


The reason for using TRUE and FALSE rather than 1 and 0 is simple: it
lets you say what you mean.  Someone once said that `GOSUB 9000' was
the most dismal statement in the whole of computing.  In my opinion
`boolvar = 1;' is in the same class.

To the people complaining about `if (x == TRUE)': YOU ONLY USE `TRUE' AND
`FALSE' FOR ASSIGNMENT AND PARAMETER PASSING.  It's a fairly simple rule.

I'd be interested to see some experiments with adding a `bool' type to a
C compiler (gcc?), with the following semantics:

	- bool has the same size and representation as int.

	- the comparison operators yield bool as the result type.

	- the `&&', `||' and `!' operators demand bool operands and
	  yield a bool result.  The ?: operator demands bool as its
	  first operand.  The only other operators that take bool
	  operands are `!=', `==' and `&' (address of).
	
	- `if', `do/while', `while' and `for' demand a bool expression
	  as the test.   Note that `if (ptr)' is still allowed by the
	  implicit rewrite to `if (ptr != 0)'.

	- assignment and comparison between bool and arithmetic types
	  is illegal without a cast, except for assignment to a bool
	  lvalue of an integral constant expression with the value 0 or 1.

This would provide some useful extra type checking, especially now that
we have function prototypes.  If `typedef int bool;' was allowed as a
special case, then code portability wouldn't be affected.

One weakness of this scheme is that it forces bool variables to take
the same space as an int.  I'm not sure whether adding `shortbool'
and `charbool' types (with appropriate conversion rules) would be worth
the additional complexity.  Programmers can always use casts.

BTW: these rules would reject `bool gotdigit = isdigit(c)', and rightly.

Mark Russell



More information about the Comp.lang.c mailing list