Boolean datatypes

Ray Butterworth rbutterworth at watmath.UUCP
Thu Jun 19 00:07:01 AEST 1986


The X3J11 draft says that enums are type (int).  This is probably a
mistake since they should be at least type (size_t) as they are handy
for defining specific index values into arrays.

But even though they are more or less equivalent to #defines as far
as the compiler is concerned, there is no reason that lint can't
treat them specially.  In particular it should allow subscripting,
switching, and if(b) and if(!b) without any complaint, but it should
complain about function parameters or other attempts to implicitly
cast them to a different type.

Incidentally, since they are used the same as #define manifests,
as a matter of style we always make the enum constant have an
all upper-case name (e.g. TRUE) just as we do for all #define
manifest names.  As far as the programmer is concerned they are
used identically so he shouldn't need to know whether they are
enums or manifests.  And if we have to move to a compiler that
doesn't have enums, making them manifests in the header files
is easy.  Similarly we make #define macros all upper-case if
they have side-effects on the arguments, but all lower-case if
they are indistinguishable from functions in usage.

As was pointed out, the biggest problem with an enum Boolean is
in assigning "b=(a==c)" or "return (a==c)".  We use this typedef
frequently, and this particular problem doesn't arise that often.
When it does, it really isn't that difficult to have to say
"b=(Boolean)(a==c)" or "return (Boolean)(a==c)", or to have
#define BOOLEAN(x) ((Boolean)(x))
and then "b=BOOLEAN(a==c)" or "return BOOLEAN(a==c)".



More information about the Comp.lang.c mailing list