Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!srhqla!demott!kdq
From: kdq@demott.COM (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: TRUE and FALSE
Message-ID: <514@demott.COM>
Date: 22 Aug 90 15:56:37 GMT
References: <11215@alice.UUCP>
Reply-To: kdq@demott.COM (Kevin D. Quitt)
Organization: DeMott Electronics Co., Van Nuys CA
Lines: 39

In article <11215@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>In article <12249@netcom.UUCP>, ergo@netcom.UUCP (Isaac Rabinovitch) writes:
>
>> On the other hand, you can say (and I used to) that using 1 and
>> 0 instead of TRUE and FALSE is a similar "familiar practice", since any
>> competant C programmer knows that C booleans are just integers.  
>> In this case it probably makes a big difference that TRUE and FALSE are
>> ordinary English words, not obscure acronyms.
>
>Unfortunately, using TRUE and FALSE opens a great gaping hole:
>one would expect that
>
>	x == TRUE
>
>would mean the same as
>
>	x != FALSE
>
>but of course it doesn't -- at least not if you use the usual C
>convention that 0 is false and any other value is true.


    We use 

#define	TRUE	(1==1)
#define	FALSE	(1!=1)

    defined that way for hysterical raisins (broken compiler).  We are
aware of the problem above, and never test booleans that way.  TRUE and
FALSE are used for assignment purposes only.  It makes the intent of the
code more obvious. 

-- 
 _
Kevin D. Quitt         demott!kdq   kdq@demott.com
DeMott Electronics Co. 14707 Keswick St.   Van Nuys, CA 91405-1266
VOICE (818) 988-4975   FAX (818) 997-1190  MODEM (818) 997-4496 PEP last

                96.37% of all statistics are made up.