Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!cmcl2!rutgers!topaz.rutgers.edu!ron From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.lang.c Subject: Re: Defining TRUE and FALSE Message-ID: <13259@topaz.rutgers.edu> Date: Fri, 10-Jul-87 11:34:42 EDT Article-I.D.: topaz.13259 Posted: Fri Jul 10 11:34:42 1987 Date-Received: Mon, 13-Jul-87 03:45:20 EDT References: <13851@watmath.UUCP> <632@itsgw.RPI.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 39 Keywords: boolean, true, false Poeple seem to be missing the point. If you are going to define your own boolean type, it doesn't matter what you use for TRUE and FALSE as long as you're consistant. TRUE can be 't' and FALSE could be 'f' as long as you always use them that way. The problem is that C defines FALSE to be zero and TRUE to be non zero. Hence, while you may define FALSE to be 0, there is nothing you can define true to be that will consistantly work as things that set true values are free to use any non-zero number. The correct test for truth is the value by itself, for example if(expr) while(expr) for(;expr;) expr ? x : y FALSE can either be !expr or expr == 0 (or its #define'd equivelents). --------------------------------------------------------------------- On a different light, I've noticed nobody has mentioned the construct of seting a variable of TRUE by incrementing it. Many, many programs process their options by code like the following: switch(*argv[1]) { case 'b': bflag++; break; case 'c': cflag++; break; The flag variables are unitialized extern chars (and hence are zero). Some times however, this approach is used inside of loops, I avoid using this because I am always afraid that someday someone will cause the code to be executed exactly 256 times. -Ron