Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > 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) Eek, it defeats the benefit of using true Boolean type if we had to train ourselves to write the former, doesn't it? > 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) Nice to be reminded of this one. The cited commit does not start to use any specific feature from C99, other than that we now require that the compiler claims C99 conformance by __STDC_VERSION__ set appropriately. The commit log message says C99 "provides a variety of useful features, including ..., many of which we already use.", which implies that our wish was to officially allow any and all features in C99 to be used in our codebase after a successful flight of this test balloon. Now, I think we saw a successful flight of this test balloon by now. Is allowing all the C99 the next step we really want to take? I still personally have an aversion against decl-after-statement and //-comments, not due to portability reasons at all, but because I find that the code is easier to read without it. But in principle, it is powerful to be able to say "OK, as long as the feature is in C99 you can use it", instead of having to decide on individual features, and I am not fundamentally against going that route if it is where people want to go. Thanks.
