Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!asuvax!mcdphx!hrc!gtx!al
From: al@gtx.com (Alan Filipski)
Newsgroups: comp.lang.c
Subject: BOOLEAN as enum
Message-ID: <1199@gtx.com>
Date: 28 Mar 90 21:35:45 GMT
Reply-To: al@gtx.UUCP (Alan Filipski)
Organization: GTX Corporation, Phoenix
Lines: 55


It has been proposed around here to define a Boolean type as

          typedef enum {FALSE, TRUE} BOOLEAN;

to me there seems to be very little difference between this and the more
usual

          #define FALSE 0
          #define TRUE 1
(and, optionally, either typedef int BOOLEAN or typedef char BOOLEAN)


The only difference I see is that lint could complain about some
clashes, as in

           BOOLEAN p() 
          { 
             return 99; 
          } 

or



           BOOLEAN x;
           x = 10; 

which complaints might be useful.  however, lint would then also
complain about things like:

          x = (a==b);

or
           BOOLEAN p()
          {
             return (a==b);
          }


which one probably does not want to see complaints about
(but which could be circumvented with a logically gratuitous cast).

anyway, my question is this: aside from possible lint messages,
does the ANSI model for enums imply any difference between the
enum or #define approach to TRUE/FALSE?  My personal opinion is that,
since neither approach provides a real BOOLEAN type, one
should stick with customary usage.  Comments?



  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ( Alan Filipski, GTX Corp, 8836 N. 23rd Avenue, Phoenix, Arizona 85021, USA )
 ( {decvax,hplabs,uunet!amdahl,nsc}!sun!sunburn!gtx!al         (602)870-1696 )
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~