Xref: utzoo comp.lang.c++:4755 comp.lang.c:22148
Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!gem.mps.ohio-state.edu!apple!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: Time to standardize "true" and "false"
Keywords: true false C C++
Message-ID: <11126@smoke.BRL.MIL>
Date: 21 Sep 89 21:04:27 GMT
References: <13730@well.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <13730@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>     I would suggest that the standardized definition be
>	const boolean (false=0, true=1);

I don't know what that is supposed to mean; it's not C.

>     It should be mandated that this definition be a part of the C
>and C++ header files, preferably in an ANSI-specified file.

The result of a nominally Boolean expression in C is well-defined;
it has int type with value 1 for true, 0 for false.

>"stddef.h" seems a likely choice, but this is open to discussion.

Not really.

There is no problem insofar as the C Standard goes; "bool", "true",
etc. are not reserved words and have no special meaning.  The
problem you describe comes about only when you #include headers
for several unrelated (or at least uncoordinated) libraries.
In such a case, this is merely a small part of a name-space clash
problem.  You should address the general problem instead of one
small aspect of it.