Time to standardize "true" and "false"

[Michael Condict]

In article <12070 at cit-vax.Caltech.Edu> wen-king at cit-vax.UUCP (Wen-King Su) writes:
>In article <393 at cpsolv.UUCP> rhg at cpsolv.uucp (Richard H. Gumpertz) writes:
>>The biggest advantage of a built-in boolean type would be that casts TO it
><would test for zero/non-zero rather than just trucating the high-order bits
>>if sizeof(source) is bigger than sizeof(bool).  Also,  . . .
>
>Why not just do:
>
>#define bool(a) (!!(a))
>
>Then just use bool(X) whenever you wanted to use (bool)X.
>

Because neither lint nor the C compiler will help you find the places where
you forgot to use bool(X).  Presumably, ints would be cast to the proposed
Boolean type automatically, as needed.  Or the two types would be incompatible
and require an explicit cast to avoid an error message (except when ints are
used in the bool-expr of a while loop or if statement).

One of the biggest problems with C, compared to strongly typed languages
like Pascal, is that it doesn't help you enough in finding type mismatch
errors.  ANSI C does not solve this problem completely, although its
function prototypes at least allow compilers to do their weak type checking
across function boundaries, as well as within a single compilation unit.
Unfortunately the only cases for which the weak type checking produces error
messages is when pointers and numeric types, or two different pointer types,
are mixed.

Consider the case where you have a function that expects a float, an int and
a char.  In most cases, you the programmer consider these to be different,
incompatible types, and would consider it an error to pass a character
constant in the place where the float is expected.  This would almost cer-
tainly indicate that the caller got the order of the parameters wrong.
C, on the other hand, happily (and quietly) converts the character, which
is a numeric type, to a float, in the presence of a prototype.  In the absence
of a prototype, lint will complain about the mismatch of the char and float,
but will not complain if you get the order of the char and int parameter
wrong.

The issue is this: is a programming language always more powerful when it
accepts a given construct, rather than rejecting it with an error message?
Or is it sometimes weaker?  Opinions differ when specific constructs are
discussed, but I doubt if anyone would want to go back to the bad old
days when integers and pointers were compatible types and could be
interchanged freely.

Michael Condict    condict at cs.vu.nl
Vrije University