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 | ==========================================================================