Xref: utzoo comp.lang.c:31619 alt.lang.cfutures:33 Path: utzoo!utgpu!cs.utexas.edu!yale!mintaka!spdcc!ima!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.lang.c,alt.lang.cfutures Subject: A builtin boolean type Message-ID: <17634@haddock.ima.isc.com> Date: 5 Sep 90 19:43:59 GMT Reply-To: karl@kelp.ima.isc.com (Karl Heuer) Followup-To: alt.lang.cfutures Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 65 This is getting off-topic for comp.lang.c, so I'm taking it to alt.lang.cfutures. In articles <5398@harrier.ukc.ac.uk> <5409@harrier.ukc.ac.uk> mtr@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 . 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 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@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.)