From: Junio C Hamano <gitster@pobox.com>
To: Arnav Bhate <bhatearnav@gmail.com>
Cc: git@vger.kernel.org, Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [GSoC PATCH v2] pathspec: fix sign comparison warnings
Date: Sat, 29 Mar 2025 11:36:45 -0700 [thread overview]
Message-ID: <xmqqr02fd6pu.fsf@gitster.g> (raw)
In-Reply-To: <aa7753f2-27f5-4a7a-830d-780bd21191f7@gmail.com> (Arnav Bhate's message of "Sat, 29 Mar 2025 11:47:36 +0530")
Arnav Bhate <bhatearnav@gmail.com> writes:
> @@ -43,12 +42,12 @@ void add_pathspec_matches_against_index(const struct pathspec *pathspec,
> * mistakenly think that the user gave a pathspec that did not match
> * anything.
> */
> - for (i = 0; i < pathspec->nr; i++)
> + for (int i = 0; i < pathspec->nr; i++)
> if (!seen[i])
> num_unmatched++;
> if (!num_unmatched)
> return;
> - for (i = 0; i < istate->cache_nr; i++) {
> + for (unsigned int i = 0; i < istate->cache_nr; i++) {
> const struct cache_entry *ce = istate->cache[i];
> if (sw_action == PS_IGNORE_SKIP_WORKTREE &&
> (ce_skip_worktree(ce) || !path_in_sparse_checkout(ce->name, istate)))
Makes me wonder if it is a nicer solution for longer term to count
items in "struct pathspec" with unsigned, not signed int. A local
variable that needs to hold the number of items plus an extra bit
that signals an invalid state (typically denoted by a negative
number) needs to be signed, but a member in a struct that records
number of items in an array in the same struct has no reason to be
of signed type, as the invalid state could just be represented by
the .item being NULL.
But let's leave it for later; it is not something we want to leave
GSoC students to handle.
> @@ -845,7 +844,7 @@ int pathspec_needs_expanded_index(struct index_state *istate,
> * - not-in-cone/bar*: may need expanded index
> * - **.c: may need expanded index
> */
> - if (strspn(item.original + item.nowildcard_len, "*") == item.len - item.nowildcard_len &&
> + if (strspn(item.original + item.nowildcard_len, "*") == (unsigned int)(item.len - item.nowildcard_len) &&
> path_in_cone_mode_sparse_checkout(item.original, istate))
> continue;
>
> @@ -860,7 +859,7 @@ int pathspec_needs_expanded_index(struct index_state *istate,
> * directory name and the sparse directory is the first
> * component of the pathspec, need to expand the index.
> */
> - if (item.nowildcard_len > ce_namelen(ce) &&
> + if ((unsigned int)item.nowildcard_len > ce_namelen(ce) &&
> !strncmp(item.original, ce->name, ce_namelen(ce))) {
> res = 1;
> break;
These lines in these two hunks are way overly long already in the
original, and extra casts make the even worse. Perhaps fold them
in the middle appropriately?
next prev parent reply other threads:[~2025-03-29 18:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 20:20 [GSoC PATCH] pathspec: fix sign comparison warnings Arnav Bhate
2025-03-13 12:52 ` Karthik Nayak
2025-03-13 14:20 ` Arnav Bhate
2025-03-13 14:44 ` Karthik Nayak
2025-03-13 15:33 ` Junio C Hamano
2025-03-13 15:50 ` Karthik Nayak
2025-03-16 10:14 ` Arnav Bhate
2025-03-29 6:17 ` [GSoC PATCH v2] " Arnav Bhate
2025-03-29 6:18 ` Arnav Bhate
2025-03-29 18:36 ` Junio C Hamano [this message]
2025-03-30 17:45 ` [GSoC PATCH v3] " Arnav Bhate
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=xmqqr02fd6pu.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=bhatearnav@gmail.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@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).