Ashtead's Journal: No BOOLs in software please

This one made me laugh, but I'm not surprised really, as I have long been of the opinion that defining a specific boolean data type never was a good idea. And here is Exhibit N, GetMessage(). To wit:

BOOL GetMessage(LPMSG lpMsg, HWND hwnd, UINT wMsgFilterMin, UINT wMsgFilterMax)

Now, BOOL was originally ment for the Boolean, two-state "Yes/No" kind of value, such as in the original intention of indicating progress or halt for this particular function. But this turned out not to be future-proof: Further down on the page there is:

Warning Because the return value can be nonzero, zero, or -1, avoid code like this [...] The possibility of a -1 return value means that such code can lead to fatal application crashes."

Well, I'll say! Nice of Microsoft to tell us this. Nevermind the original, and now ossified definition of BOOL, which fortunately was just the same as an int back in the day.

And note, this isn't MS bashing. I have never found the concept of explicit Boolean typed variables to be particularly useful anywhere under any operating system. Flags and bits in variables, being 1 or 0 or on or off or some other dichotomy, yes, but these are always very context-specific, much like the original pass/stop meaning of GetMessage() above. Booleans work fine for logic gates where all signals are Low or High, not for code where values appear as 0 or 1.

There is a fairly old meme, enum BOOLEAN {TRUE, FALSE, FILE_NOT_FOUND} which illustrates this perfectly on the Daily WTF site

(For some reason (very likely some corporate misgivings causing the site to be banned because of profanity) this has recently been sanitized from the traditional "What The Fuck" to the arguably safer for work "Worse Than Failure".)

The days when bool was truly useful

[Marxist Hacker 42]

are long gone. I don't know of a single language or operating system today that implements them properly. Proper implementation of a bool fits 8 of them in a single byte (implemented as a pointer to a memory location and a bitmask to be ANDed to find the value of the variable).

Having said that- today's bools need proper definitions of either true or false. In Microsoft land, True is defined as Not (False) and False=0; if you code for that then you'll be OK even if you get -1 as the response.

Re:

[Bill Dog]

I haven't uncovered anything improper with C++'s bool type. And I'm assuming that, since C++ cares about efficiency, that its (proper) implementation is according to the natural word length of the machine, rather than a more compact but slower-to-access format.

Having a boolean type at your disposal has value because it lends explicitness, and explicitness is of value in programming.

Re:

[Marxist Hacker 42]

Yes- but the point is, even if you don't have a bool type built in, you can emulate one yourself pretty easily. In C++, for example, bool is exactly the same as type word, with a couple of predefined constants.

In the old days of programming, the purpose of bool was for compact, fast running code. Boolean algebra is the native language of the processor itself- EVERYTHING is built on top of the NAND gate. If you could code a knowledge base in terms of true and false, it could spit out answers faster than

Re:

[Ashtead]

The explicitness is useful as long as it is correct. When the nominally two-state variable starts distinguishing between more than the simple true/false or pass/stop dichotomy, it stops being useful and starts being confusing. And since this style of variable really is a full-fledged int behind the scene, such extensions are physically possible. I've seen another, older, case of multivalued BOOL usage, in dialog-box functions, one of the message may return a handle to some GUI element in addition to the exp

Re:

[Bill Dog]

The explicitness is useful as long as it is correct. When the nominally two-state variable starts distinguishing between more than the simple true/false or pass/stop dichotomy, it stops being useful and starts being confusing.

Unfortunately that's the very same problem with just using ints for bools:

int someFlag1 = 0; // all bits zero, so false
int someFlag2 = -1; // all bits one (in two's complement), so true

int someFlag3 = -1;
int someFlag4 = ( someFlag2 == someFlag3 );

int someFlag5 = 0;
if ( someFlag4 == som

moof

[Bill Dog]

I wonder if in 16-bit Windows that function didn't have the error checking and -1 return possibility. My old Win95 Petzold book teaches the warned-against usage, but that may have just been carried over from his Win3.1 book.

Interesting that MS didn't leave this alone and just deprecate it and add a GetMessageEx(). It looks like they'd rather apps crash than expose a vulnerability, which I suppose is the right choice.