On Friday 29 January 2010, Andreas Fritiofson wrote: > On the other hand, code that relies on specific values for true is > IMHO buggy or at least error prone (especially if "true" == -1!!), > which implies that the define shouldn't be used at all in comparisons.
That was implicit in the point I made about C having multiple truth values ... visible in "while (X)", "if (X)", etc. >From my perspective, C always worked fine without a boolean type. However, some folk are still bothered by the fact that it's not Pascal. :) > That includes pointless constructs like "if ((a == b) == true) ..." That's a degenerate case of some *NON*-pointless code which assigns a variable to the result of "a == b" and uses it later. Such use can end up using comparisons, sometimes implicitly. (I remember chasing bugs in such areas caused by using values other than one as the designated truth value...) > except with real boolean types (and if there's a bool type there's > certainly a built-in true as well). It could perhaps be useful in > assignments, though. Bit array support would have made much sense. The "bool" type is overall just a minor improvement, IMO. If it's going to be used, it should be used correctly. I find it odd that clang doesn't support it though... _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
