4 ms·

Even after reading all the comments I am not sure should I use bool in C code or not. I am C++ programmer only starting to have some fun in C. Linus says: If "

Even after reading all the comments I am not sure should I use bool in C code or not. I am C++ programmer only starting to have some fun in C. Linus says: If "bool" had real advantages (like having a dense array representation, for example). But doesn't bool have the advantage of reducing perceived complexity of the code and making the code more understandable? If the function returns int, one might assume it is some number, and he would have to use documentation or look at code samples to find out the int is only being compared to 1 or 0. Type bool instantly tells there's some kind of check or flag that is returned, and makes it undoubtedly easier to tell what's going on. As for casting rules other mentioned, doesn't the C compiler warn about anything converting to anything that can store less information than what it converts from?

pavlov 13y ago
Normally you get a warning when the destination type is smaller, but with C99 bool you don't because that's how the standard is written: any non-zero value of any other type is implicitly converted to "true". That's why C99 bool typecasting problems are so subtle. If you were previously using typedef char BOOL and you switch to the "real" bool, you don't get compiler warnings about suspicious casting anymore.
- andrewcooke 13y ago
  but you don't have the bug either, right? because it doesn't take only the first byte. so what's the problem? (genuine question - have never used _Bool and am trying to get a handle on this thread).
  - pavlov 13y ago
    Indeed, the C99 bool fixes this particular bug, but it can introduce new bugs because its semantics are different from other C types. C99 bool allows you to assign a larger integer or a pointer to a bool with no warning. As illustrated by the grandparent commentor, the general assumption is that the C compiler will always warn you about these situations. If bool had been always been part of the standard, people would be aware of this issue. But it wasn't, and so the C world is full of BOOL typedefs that can be chars, ints or whatever, and it's easy for programmers to implicitly assume that the "real" bool behaves like the typedefs they're used to.
coldtea 13y ago
>But doesn't bool have the advantage of reducing perceived complexity of the code and making the code more understandable? You cannot reduce "perceived complexity" by adding subtle error cases, i.e actual complexity.
cygx 13y ago
My personal advice: If you're starting a new codebase and don't have to care for legacy compilers, use it. Otherwise, it's a case by case decision. I agree that you should never typedef a type different than _Bool to bool if you want to avoid a world of hurt, and I'd argue that using true and false in a C codebase is harmful as well.
EpicEng 13y ago
Anyone who writes C understands the int -> Boolean expression just fine. There's nothing more clear a out bool. Really, it's not a tough rule to grok.

pavlov 13y ago

Normally you get a warning when the destination type is smaller, but with C99 bool you don't because that's how the standard is written: any non-zero value of any other type is implicitly converted to "true". That's why C99 bool typecasting problems are so subtle. If you were previously using typedef char BOOL and you switch to the "real" bool, you don't get compiler warnings about suspicious casting anymore.

andrewcooke 13y ago
but you don't have the bug either, right? because it doesn't take only the first byte. so what's the problem? (genuine question - have never used _Bool and am trying to get a handle on this thread).
- pavlov 13y ago
  Indeed, the C99 bool fixes this particular bug, but it can introduce new bugs because its semantics are different from other C types. C99 bool allows you to assign a larger integer or a pointer to a bool with no warning. As illustrated by the grandparent commentor, the general assumption is that the C compiler will always warn you about these situations. If bool had been always been part of the standard, people would be aware of this issue. But it wasn't, and so the C world is full of BOOL typedefs that can be chars, ints or whatever, and it's easy for programmers to implicitly assume that the "real" bool behaves like the typedefs they're used to.

coldtea 13y ago

>But doesn't bool have the advantage of reducing perceived complexity of the code and making the code more understandable? You cannot reduce "perceived complexity" by adding subtle error cases, i.e actual complexity.

cygx 13y ago

My personal advice: If you're starting a new codebase and don't have to care for legacy compilers, use it. Otherwise, it's a case by case decision. I agree that you should never typedef a type different than _Bool to bool if you want to avoid a world of hurt, and I'd argue that using true and false in a C codebase is harmful as well.

EpicEng 13y ago

Anyone who writes C understands the int -> Boolean expression just fine. There's nothing more clear a out bool. Really, it's not a tough rule to grok.