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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio

On 15/12/2023 17:09, Junio C Hamano wrote:
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?

Yes, it's horrible - if for some reason it turns out that we cannot use "#include <stdbool.h>" everywhere I think we should drop it rather than providing a subtly incompatible fallback

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.

I'm not sure we necessarily want to say "use anything that is in C99" for several reasons.

 - Some features such as C99's variable length arrays are known to be
   problematic.

 - As you say above there maybe features that we think harm the
   readability of our code.

 - As René points out not all compilers necessarily support all
   features.

I think using _Bool could be useful for the reasons Peff outlined. As for other features I've written code that I think would have benefited from compound literals, but off the top of my head I can't think of any other C99 features that I personally wish we were using. I think that decl-after-statement is occasionally useful to declare a variable near where it is used in a long function body but it is much simpler just to ban it altogether and encourage people to break up long functions to make them more readable.

Best Wishes

Phillip

Thanks.






[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux