More on BOOLEAN vs. boolean

[KW Heuer]

In article <559 at brl-smoke.ARPA> HARGED%ti-eg.csnet at CSNET-RELAY.ARPA writes:
>>o  Multiple flag variables with local scope and no address operator (e.g.
>>   variables declared "register bool") could be packed into a single word.
>
>*IF* packing bits is feasible on your host machine. (Whether you like it or
>not) there are many C implementations that can't afford the overhead of bit
>packing.

The bits don't need to be explicitly packed and unpacked except to convert
between bool and int.  Otherwise a bit-test, bit-set, and bit-clear will do,
I think; these are just "&", "|", and "&~", and are very common instructions.
(Anyway, an implementation is free to NOT pack the bits, just as it can put
a char in a 32-bit word if the alternative is too much trouble.)

>>o  "++x" and "--x" could be defined as "set" and "clear"; "x++" and "x--"
>>   would then be "test and (set|clear)".  This would obviate such things as
>>   "if (!flag) { flag=1; printmsg(); }".
>
>I think the same problems with doing that now (on integers of whatever size)
>would plague the boolean type. The code that would have to generated to avoid
>giving a boolean variable an undefined value would probably match the size
>of the code currently generated when the user explicitly controls a flag's
>value.

Actually, I was introducing "x++" for the user's benefit, not the machine's.
I wouldn't mind if it generated the same code as in the explicit case; after
all, it's only two instructions (test, followed by store-constant).  However,
I'd expect a machine with an efficient test-and-set instruction to use it.

>However, (~x) for "toggle" would be useful. The lack of an efficient
>toggle operation on integer BOOLEAN's is sometimes a pain.

I see no reason to change it from "!" to "~".  The only case where it's
inefficient now is with "x = !x", which could indeed be optimized if "x" is
known to be boolean rather than int.  (Of course you can write "x ^= 1".)

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint