Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: TRUE and FALSE
Message-ID: <17632@haddock.ima.isc.com>
Date: 5 Sep 90 18:50:54 GMT
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 73

[Lots of people have said:]
>Writing `if (b == TRUE)' is wrong.

No.  It's correct but silly (as is `if ((x < y) == TRUE)').  The flaw is in
writing `b = isdigit(ch)', because `isdigit()', despite the misleading name,
is *not* a Boolean function.  If this had been done right, the function would
be guaranteed to return the normalized truth value, namely 1, on success.
(Fixed in INTERACTIVE Unix, incidentally.  It's no less efficient under normal
usage, and less error-prone under abnormal usage.)


In article <3686@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>Let's not forget the Lisp Lesson:  there is often something useful you
>could return instead of an anonymous "true".

Fine; functions that have that property can be declared with a type other than
"bool".  Functions that don't have any useful value to return on success can
and should return TRUE.  (fgets() was another mistake.)

>Why should your proposed C variant be more restrictive than Pascal?
>In Pascal FALSE < TRUE is allowed, meaningful, and true.

For the same reason that it's more restrictive than current C.  The relation
b1 < b2 isn't sufficiently useful to be worth supporting, IMHO (since it's
equivalent to !b1 && b2); and forbidding it may make it possible to catch real
mistakes.


In article <898@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>K&R tried to make this very easy with C ... they LEFT OUT out a
>"boolean" or "logical" datatype and gave *very simple* rules for
>using int for that purpose.

Hey!  They could have made it *even simpler*, by making `int' and `float' the
same type, like in BASIC or APL!  (Sarcasm alert.)

Conceptually, C already has booleans: the operands of various control-flow
statements and operators; the results of relationals, etc.  The usual
description of the language is in terms of `int', but it would be equally
correct to say that `a < b' returns an object of type Boolean, and that
Booleans and integers are implicitly converted by the rules `i=(b?1:0)'
and `b=(i!=0)', and that there is no keyword for Boolean (and hence one may
not declare objects of that type, but must instead fall back on int).

>And how have you made sure that the readers have grasped *your* strict rules
>when and when not to use TRUE and FALSE and will apply it correctly?

It's not as if everyone is making up their own rules.  Not mixing Boolean and
integer data should simply an `obvious' rule, like not mixing pointers and
ints (even if you happen to be using a language that's sloppy about it--C in
the first case, BCPL in the second).

>[Why not use the names SET/CLEAR, YES/NO, ON/OFF, SUCCESS/FAILURE instead]?
>Is it because most of you (still) grew up with PASCAL?

Probably.  I use YES/NO myself, following Kernighan I believe, but I've
noticed it's a minority position.  If <bool.h> were standardized, I'd switch
to whatever it used.

>And a final word to the ones who advocate "strong typing": You should
>clearly vote for differently typed truth values: If you are reluctant when
>it comes to mixing (integer) numbers with truth values, you should
>clearly vote for *differently named* constants for different sorts
>of truth values.

This is true to some extent (and applies to other types as well as Booleans),
but (a) mixing apples and oranges is sometimes the right thing (how do you do
a matrix multiply if you've typedef'd `row_index' and `col_index'?), and (b)
at some point it just becomes too much work to declare a new type for an
object that has a small scope.  (Though if the compiler enforced the
type-mixing restriction, it might be worthwhile.)

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint