4 ms·
In the example you gave, any compiler from the last 10 years would have given a warning message when converting the pointer to an int. Ignoring error messages
by cmccabe 13y ago
In the example you gave, any compiler from the last 10 years would have given a warning message when converting the pointer to an int. Ignoring error messages is extremely, extremely bad practice. If you are still doing that, I suggest auditing your code right now to see if there are more problems such as mismatched printf arguments and so forth.
bool is a bad thing in C and C++, because of the implicit conversion rules. In C++, pointers implicitly convert to bool in every context-- there is never any warning message. This effectively reduces the compiler's ability to typecheck your program, since so many variables are pointers already, and C++ will happily stuff them into any bool argument to a function.
It seems like the C99 _Bool type implements the same implicit type conversion brain damage. That makes it a step backwards in terms of type safety, not forwards. That's right, using the old-fashioned, fuddy-duddy, plain old int and 0 and 1 gives you better type checking than the shiny new C++ feature.
As Linux points out, the worse typechecking comes with a side order of compatibility problems. And it is not any more efficient or readable.
- rwg 13y agoIt seems like the C99 _Bool type implements the same implicit type conversion brain damage. It does: "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." (from §6.3.1.2 of the N1256 draft) Compilers will happily compare/set pointers to 0 since that's the null pointer constant (§6.5.9, §6.3.2.3), so there's no warning: % cat foo.c #include <stdio.h> int main() { _Bool b = "blah"; printf("%d\n", b); return 0; } % gcc -std=c99 -W -Wall -Wextra -o foo foo.c % ./foo 1
- comex 13y agoHave you ever actually encountered a bug involving accidentally passing a pointer to a 'bool' function argument? I've seen many obscure kinds of bugs, but don't remember ever in my life seeing one of those- so I suspect this is a red herring. (And of course if the value passed happens to be an int rather than a pointer, typedefing bool to int won't save you!) edit: And as mentioned in the rest of the thread, while it's unjustifiably confusing to, say, pass 'p' as a boolean parameter rather than 'p != NULL', it's not unreasonable to do something like typedef int bool; bool foo_enabled; void set_foo_enabled(bool enabled) { if(enabled == foo_enabled) return; /* new value is different, do some work */ } set_foo_enabled(1); ... set_foo_enabled(flags & ENABLE_FOO); Though I haven't come across this kind of bug in practice either.
- bzbarsky 13y agoI've encountered a bug like that when the callee was converted from taking a pointer to taking a bool and the caller was not updated because it compiled fine...
- deleted 13y ago[deleted]