Yes, sure, but why design a language that way? Who is it helping? No language implementer WOULD do that to an int. My development group avoids bool like the plague, using int instead - it has well-defined size, behavior and sensible warnings.

>Yes, sure, but why design a language that way? Who is it helping?

Compiler writers. C exists mostly to be a portable language that's easy to compile. A better question is why would you write programs in C in 2012.

>No language implementer WOULD do that to an int. It certainly happened to float/double on some older architectures where the internal representation included different flag bits. I wouldn't be at all surprised if it happened to char and short. I guess there's an argument for using int for all variables in your program (since memory isn't usually constrained enough nowadays for it to be worth using short etc.), but again, if you weren't memory-constrained why would you be using C?

>My development group avoids bool like the plague, using int instead - it has well-defined size, behavior and sensible warnings

Int might not suffer from this particular behaviour, but if you use an uninitialized variable it will bite you sooner or later. The article's takeaway isn't "avoid bool", it's "initialize your variables"

Maybe you misapprehend the bool issue? It isn't that bool doesn't match a register; its that the value is stored in memory in a subset of the storage unit i.e. 1 bit out of the byte. That's not true of any other scalar.

Suppose you have a char followed by a long in a struct; the compiler will insert seven bytes of padding after the char. There's nothing to prevent it setting the padding to 0 when initializing the char, and using a 64-bit load instruction to load it into a register - in which case you'd get exactly the same behaviour as seen here with bool, only even more confusing.