A builtin boolean type

Karl Heuer karl at haddock.ima.isc.com
Thu Sep 6 05:43:59 AEST 1990


This is getting off-topic for comp.lang.c, so I'm taking it to alt.lang.cfutures.

In articles <5398 at harrier.ukc.ac.uk> <5409 at harrier.ukc.ac.uk> mtr at ukc.ac.uk (M.T.Russell) writes:
>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.

Why guarantee anything of the sort?  Leave it up to the implementation.  A
smart compiler can even pack them into single bits when appropriate.  (Those
12 flags declared `register bool' in main() might as well share one register!)

>- `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)'.

I'd strike that last sentence.  If you're going to add strict-checking
Booleans, then the user should have to make the comparison explicitly, whether
the operand is a pointer or any arithmetic type.

>- assignment and comparison between bool and arithmetic types
>  is illegal without a cast.

I suppose a cast could be legal, though I think `b=(i!=0)' and `i=(b?1:0)' are
better ways to write the conversions.

>If `typedef int bool;' was allowed as a special case, then code portability
>wouldn't be affected. ... I'd also turn on a macro __BOOL__ to indicate that
>the extension was there, so that applications could say:
>	#ifndef __BOOL__
>	typedef int bool;
>	#define TRUE 1
>	#define FALSE 0
>	#endif

Better yet, here's how to retain full backward compatibility.  I'll phrase it
in terms of what I think the ANSI Standard should have (roughly) said:

The implementation shall provide a header <bool.h>.  It defines the type
"bool" and the constants "TRUE" and "FALSE" of that type.  Including
this header may also enable strict typechecking of Booleans.  Thus, an
implementation is conforming by simply providing this header with the single
line "typedef enum { FALSE, TRUE } bool;", but a stricter implementation
may choose to say
	#pragma enable_warnings_strict_bool
	typedef __builtin_bool bool;
	#define TRUE __builtin_true
	#define FALSE __builtin_false

All operators that are conceptually Boolean (e.g. "<") return a result of type
bool, not int.  All the obvious operators and statements (e.g. "if()") expect
an expression of type bool, not int.

A bool which appears in an int context is automatically converted as if by
`b?1:0', and an int (or pointer) that appears in a bool context is
automatically converted as if by `i!=0'.  (Backward compatibility.)

Common warnings: the program has an implicit conversion involving a bool.

(Alternately, we could say that these conversions are simply illegal if
<bool.h> has been used, but I anticipate objections from the weenies who think
"j/(i+!i)" is a feature instead of a flaw.)

Karl W. Z. Heuer (karl at kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
(P.S. I'd rather see YES/NO instead of TRUE/FALSE, but I expect I'm outvoted.)



More information about the Comp.lang.c mailing list