Hi Eric, I agree with your explanations and patch so far.
> maybe it IS worth a change to gnulib's stdbool, to > use 'int' rather than 'signed char' as the replacement, when <stdbool.h> is > broken, if only so that implicit conversion to bool does not also cause > truncation and thus your observed silent change from true to false. 'int' would not be sufficient; the idiom of testing a bit by doing flags & SINGLE_BIT_MASK is also used for 'long's; therefore 'long' would be better. But what you lose then, is that a bool[] array suddenly eats up 8 times more memory (on 64-bit machines). If programmers then go back to using char[] instead of bool[], to force small memory footprint, we've thrown out the baby with the water. > But while > it would help in this case, it might break other cases (for example, there is > existing gnulib code that relies on 'int a; bool b; int c = a + b;' giving > valid results [c is either a or a+1]). Right. When 'bool' values can be other than 0 and 1, you get into trouble at many more places. I think the compromise that Paul made by documenting the restrictions of gnulib's <stdbool.h> was reasonable. Bruno
