Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!texbell!attctc!kcdev!pars!cpsolv!rhg
From: rhg@cpsolv.UUCP (Richard H. Gumpertz)
Newsgroups: comp.lang.c
Subject: Re: Time to standardize "true" and "false"
Keywords: true false C
Message-ID: <390@cpsolv.UUCP>
Date: 24 Sep 89 15:07:55 GMT
References: <13730@well.UUCP> <20024@usc.edu>
Reply-To: rhg@cpsolv.uucp (Richard H. Gumpertz)
Distribution: comp
Organization: Computer Problem Solving, Leawood, Kansas
Lines: 31

If the type bool were a new BUILT-IN type then the compiler implementor could
decide what width (and representation values) it should have INDEPENDENTLY
from deciding int, char, etc.  This might result in more efficient
representation on a portable basis.

The casting rules from integral types to bool would no longer catch poor
programmers who write:
        #define bool char
        ...
        int mumble();
        ...
        bool failed;
        failed = mumble();
This fails for 8-bit chars when mumble returns an error code of 0x300.  The
programmer really wanted:
        failed = (mumble() != 0);
or
        failed = (!!mumble());
or
        failed = (mumble() ? true : false);
If type bool were built in, then the (implicit) cast from integral types to
bool would include the "!= 0" test automatically if needed.

Also, the precise representation of bool would now be implementor-defined: it
would only be required that casts of bool to integral types return 0 or 1; the
internal representation of bool might be different.
-- 
==========================================================================
| Richard H. Gumpertz:                        ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohwak Lane, Leawood, Kansas 66206-1749 |
==========================================================================