On Thu, Dec 14, 2023 at 02:08:31PM +0100, René Scharfe wrote:
> > I don't even know that we'd need much of a weather-balloon patch. I
> > think it would be valid to do:
> >
> > #ifndef bool
> > #define bool int
> >
> > to handle pre-C99 compilers (if there even are any these days). Of
> > course we probably need some conditional magic to try to "#include
> > <stdbool.h>" for the actual C99. I guess we could assume C99 by default
> > and then add NO_STDBOOL as an escape hatch if anybody complains.
>
> The semantics are slightly different in edge cases, so that fallback
> would not be fully watertight. E.g. consider:
>
> bool b(bool cond) {return cond == true;}
> bool b2(void) {return b(2);}
Yeah. b2() is wrong for passing "2" to a bool. I assumed that the
compiler would warn of that (at least for people on modern C99
compilers, not the fallback code), but it doesn't seem to. It's been a
long time since I've worked on a code base that made us of "bool", but I
guess that idea is that silently coercing a non-zero int to a bool is
reasonable in many cases (e.g., "bool found_foo = count_foos()").
I guess one could argue that b() is also sub-optimal, as it should just
say "return cond" or "return !cond" rather than explicitly comparing to
true/false. But I won't be surprised if it happens from time to time.
> A coding rule to not compare bools could mitigate that. Or a rule to
> only use the values true and false in bool context and to only use
> logical operators on them.
That seems more complex than we want if our goal is just supporting
legacy systems that may or may not even exist. Given your example, I'd
be more inclined to just do a weather-balloon adding <stdbool.h> to
git-compat-util.h, and using "bool" in a single spot in the code. If
nobody screams after a few releases, we can consider it OK. If they do,
it's a trivial patch to convert back.
-Peff
