From: Patrick Steinhardt <ps@pks.im>
To: Tian Yuchen <a3205153416@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v1][RFC] symlinks: use unsigned int for flags
Date: Wed, 21 Jan 2026 10:39:23 +0100 [thread overview]
Message-ID: <aXCey7ysfqORONXr@pks.im> (raw)
In-Reply-To: <CA+rU_o6Mrw9ga0TST6p+8MANYaNGiKP9qud8izHL+hwxou9upA@mail.gmail.com>
On Tue, Jan 20, 2026 at 11:36:25PM +0800, Tian Yuchen wrote:
> Me as total newbie to the git community (also preparing for GSoC
> 2026), welcome comments or any possible suggestions!
>
> While preparing v2 to fix the return type of lstat_cache(), a broader
> question regarding coding style came to mind:
>
> I realized that even without changing the return type, the code
> compiles and runs because of C's implicit integer conversion
> (since the flag values don't exceed INT_MAX).
>
> My question is: In the Git codebase, are such "safe" implicit conversions
> generally tolerated to minimize code churn, or is it considered a
> best practice to strictly avoid them and match types explicitly whenever
> possible?
I wouldn't say "strictly". We have lots of cases where we do in fact
rely on implicit conversions. In some cases it's a code smell, in lots
of other cases it's fine. We have tried to become a bit more mindful
around such implicit conversions as those have bitten us in the past,
but we're not on a crusade against them.
So I guess the answer is "it depends". A slow trickle of improvements in
this area does make sense, but we don't want to convert all of our code
base in large patch series just for the sake of it.
Patrick
next prev parent reply other threads:[~2026-01-21 9:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 15:22 [PATCH v1][RFC] symlinks: use unsigned int for flags Tian Yuchen
2026-01-20 15:36 ` Tian Yuchen
2026-01-21 9:39 ` Patrick Steinhardt [this message]
2026-01-21 9:33 ` Patrick Steinhardt
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=aXCey7ysfqORONXr@pks.im \
--to=ps@pks.im \
--cc=a3205153416@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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