Xref: utzoo comp.lang.c++:4792 comp.lang.c:22240 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!yale!mfci!karzes From: karzes@mfci.UUCP (Tom Karzes) Newsgroups: comp.lang.c++,comp.lang.c Subject: Re: Time to standardize "true" and "false" Keywords: true false C C++ Message-ID: <1043@m3.mfci.UUCP> Date: 25 Sep 89 19:02:28 GMT References: <13730@well.UUCP> <9464@attctc.Dallas.TX.US> Sender: karzes@mfci.UUCP Reply-To: karzes@mfci.UUCP (Tom Karzes) Distribution: comp Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 30 In article <9464@attctc.Dallas.TX.US> wjf@attctc.Dallas.TX.US (Jesse Furqueron) writes: >I would suggest rather than FALSE = 0 and TRUE = 1, that the "real" definition >of TRUE is not FALSE (TRUE = not 0), i.e. TRUE = !0. Therefore the following > >#define FALSE 0 >#define TRUE !0 That's silly. You should either assume the values that C guarantes: #define FALSE 0 #define TRUE 1 Or else assume nothing and let the compiler figure it out each time: #define FALSE (0 != 0) #define TRUE (0 == 0) Your mistake is that you're confusing C's truth test (!= 0) with its canonical true and false values (F=0, T=1). In general, the canonical true and false values in a language must behave appropriately under its true test, but there may be non-canonical values which do the same. In C, there is only one integral false value. However, there are also false pointer and floating point types. In that sense, the "!= 0" test in itself says nothing about canonical false being an integer zero. Since they should only be defined once, I think it's a bit extreme to use the latter definitions shown above, but they do provide the proper justification for 0 and 1, which are best thought of as constant folded versions of these (or similar constant expressions which generate canonical true and false values without depending on what those values are).