Re: [PATCH] Use ^=1 to toggle between 0 and 1

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Dec 15, 2023, 14:46 UTC
Message-ID: <99b3a727-36fd-4fa5-a6be-60ae6fc5911e@gmail.com>
In-Reply-To: <20231214220503.GA3320432@coredump.intra.peff.net>

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

Show 18 quoted lines

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

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"

Show 6 quoted lines

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

Show 10 quoted lines

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