On 14/12/2023 22:05, Jeff King wrote:

On Thu, Dec 14, 2023 at 02:08:31PM +0100, René Scharfe wrote:

quoted

quoted

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);}

Thanks for bring this up René, I had similar concerns when I saw the 
suggestion of using "int" as a fallback.

Yeah. b2() is wrong for passing "2" to a bool.

I think it depends what you mean by "wrong" §6.3.1.2 of standard is 
quite clear that when any non-zero scalar value is converted to _Bool 
the result is "1"

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 it is also consistent with the way "if" and "while" consider a 
non-zero scalar value to be "true".

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.

Even if it unlikely that we would directly compare a boolean variable to 
"true" or "false" it is certainly conceivable that we'd compare two 
boolean variables directly. For the integer fallback to be safe we'd 
need to write

	if (!cond_a == !cond_b)

rather than

	if (cond_a == cond_b)

quoted

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.

A weather-balloon seems like the safest route forward. We have been 
requiring C99 for two years now [1], hopefully there aren't any 
compilers out that claim to support C99 but don't provide "<stdbool.h>" 
(I did check online and the compiler on NonStop does support _Bool).

Best Wishes

Phillip

[1] 7bc341e21b (git-compat-util: add a test balloon for C99 support, 
2021-12-01)