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