From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>,
Phillip Wood <phillip.wood123@gmail.com>
Cc: Jeff King <peff@peff.net>,
AtariDreams via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Seija Kijin <doremylover123@gmail.com>
Subject: Re: [PATCH] Use ^=1 to toggle between 0 and 1
Date: Sat, 16 Dec 2023 11:46:30 +0100 [thread overview]
Message-ID: <b3c0c52b-7e12-4068-99fd-07fe4fa3da7d@web.de> (raw)
In-Reply-To: <xmqqo7erl7er.fsf@gitster.g>
Am 15.12.23 um 18:09 schrieb Junio C Hamano:
> Phillip Wood <phillip.wood123@gmail.com> 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?
Indeed.
>> [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.
C99 added a lot of features, but we already use several of them.
Support for individual features may vary, though -- who knows?
E.g. http://www.compilers.de/vbcc.html claims to support "most of
ISO/IEC 9899:1999 (C99)", yet _Bool is not mentioned in its docs (but
__STDC_VERSION__ 199901L is). It's not a particularly interesting
compiler for us, but still a real-world example of selective C99
support.
The table at the bottom of https://en.cppreference.com/w/c/99 would be
useful if it was filled out for more compilers. And it also doesn't
mention _Bool and stdbool.h.
TenDRA and the M/o/Vfuscator are the only compilers without stdbool.h
support on https://godbolt.org/ as far as I can see, but that website
doesn't have a lot of commercial compilers (understandably).
So I guess in practice we still need to check each new feature, even
though in theory we should be fine after the two-year test.
René
next prev parent reply other threads:[~2023-12-16 10:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 17:17 [PATCH] Use ^=1 to toggle between 0 and 1 AtariDreams via GitGitGadget
2023-12-12 17:29 ` Dragan Simic
2023-12-12 20:09 ` Jeff King
2023-12-12 22:30 ` René Scharfe
2023-12-13 8:01 ` Jeff King
2023-12-13 15:17 ` Junio C Hamano
2023-12-14 13:08 ` René Scharfe
2023-12-14 22:05 ` Jeff King
2023-12-15 14:46 ` Phillip Wood
2023-12-15 17:09 ` Junio C Hamano
2023-12-16 10:46 ` René Scharfe [this message]
2023-12-18 16:18 ` Phillip Wood
2023-12-16 10:47 ` [PATCH] git-compat-util: convert skip_{prefix,suffix}{,_mem} to bool René Scharfe
2023-12-18 16:23 ` Phillip Wood
2023-12-18 20:19 ` Junio C Hamano
2023-12-19 13:36 ` René Scharfe
2023-12-21 9:59 ` Jeff King
2023-12-21 9:56 ` [PATCH] Use ^=1 to toggle between 0 and 1 Jeff King
2023-12-21 15:06 ` phillip.wood123
2024-12-18 0:16 ` [PATCH v2] " AreaZR via GitGitGadget
2024-12-18 0:42 ` [PATCH v3] git: use " AreaZR via GitGitGadget
2024-12-18 2:38 ` [PATCH v4] " AreaZR via GitGitGadget
2024-12-18 16:46 ` [PATCH v5] " AreaZR via GitGitGadget
2024-12-18 16:57 ` [PATCH v6] git: use logical-not operator " AreaZR via GitGitGadget
2024-12-19 10:35 ` Junio C Hamano
2024-12-18 15:46 ` [PATCH v3] git: use ^=1 " Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3c0c52b-7e12-4068-99fd-07fe4fa3da7d@web.de \
--to=l.s.r@web.de \
--cc=doremylover123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).