threads / patch / 64308

patch[Outreachy] patch-ids: fix const correctness

Subject: [PATCH] [Outreachy] patch-ids: fix const correctness

## tl;dr

7 messages between Oct 13, 2025 and Oct 13, 2025. Diffs are folded; open one to read it.

replies: 6people: 2as markdown or json

Okhuomon Ajayi· Oct 13, 2025, 16:53 UTC · lore

The `patch_id_neq()` function received a pointer to diff options via `cmpfn_data` but cast it to a non-const type. This caused a const correctness warning and could potentially allow unintended modification of read-only data.

Fix this by casting to `const struct diff_options *` instead, removing the outdated NEEDSWORK comment in the process.

Signed-off-by: Okhuomon Ajayi <okhuomonajayi54@gmail.com>
---
 patch-ids.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Show changes to patch-ids.c +2 −2

diff --git a/patch-ids.c b/patch-ids.c
index a5683b462c..b6b808332f 100644
--- a/patch-ids.c
+++ b/patch-ids.c
@@ -41,8 +41,8 @@ static int patch_id_neq(const void *cmpfn_data,
 			const struct hashmap_entry *entry_or_key,
 			const void *keydata UNUSED)
 {
-	/* NEEDSWORK: const correctness? */
-	struct diff_options *opt = (void *)cmpfn_data;
+	
+	const struct diff_options *opt = (void *)cmpfn_data;
 	struct patch_id *a, *b;
 
 	a = container_of(eptr, struct patch_id, ent);

-- 
2.43.0

Junio C Hamano· Oct 13, 2025, 17:12 UTC · re: Okhuomon Ajayi · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:

Show 24 quoted lines

> The `patch_id_neq()` function received a pointer to diff options via
> `cmpfn_data` but cast it to a non-const type. This caused a const
> correctness warning and could potentially allow unintended modification
> of read-only data.
>
> Fix this by casting to `const struct diff_options *` instead, removing
> the outdated NEEDSWORK comment in the process.
>
> Signed-off-by: Okhuomon Ajayi <okhuomonajayi54@gmail.com>
> ---
>  patch-ids.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/patch-ids.c b/patch-ids.c
> index a5683b462c..b6b808332f 100644
> --- a/patch-ids.c
> +++ b/patch-ids.c
> @@ -41,8 +41,8 @@ static int patch_id_neq(const void *cmpfn_data,
>  			const struct hashmap_entry *entry_or_key,
>  			const void *keydata UNUSED)
>  {
> -	/* NEEDSWORK: const correctness? */
> -	struct diff_options *opt = (void *)cmpfn_data;
> +

Trailing whitespace on this line.  Remove the entire line instead.

> +	const struct diff_options *opt = (void *)cmpfn_data;
>  	struct patch_id *a, *b;
>  
>  	a = container_of(eptr, struct patch_id, ent);

I do not think this is correct. Have you even compile-tested this patch?

Later in this same function, opt is passed to commit_patch_id() function (twice), which takes non-const "struct diff_options *" that is given to diffcore_std(). And the last function in this callchain has to modify the structure to record various findings (like "did we see any changes in the diff?"), so it cannot be "const" at all.

I think patch_id_neq() that says cmpfn_data is const is the source of the problem, but that function signature is mandated by the hashmap API. I do not know if we can loosen it there in the hashmap API and if so what the argument would be, but thinking about these things is what the NEEDSWORK comment is about ;-).

Okhuomon Ajayi· Oct 13, 2025, 17:22 UTC · re: Junio C Hamano · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Thanks, that explains it.

I didn’t compile test before sending my mistake. I see now that opt is passed into commit_patch_id() (and friends) and those functions modify the diff_options structure, so making opt const is incorrect. The real issue is the mismatch introduced by the hashmap API declaring cmpfn_data as const void *, which is what the NEEDSWORK comment was flagging.

I’ll revert my local change, run a build and tests, and then think about safer alternatives (or leave the NEEDSWORK comment in place if changing the hashmap API isn’t appropriate). Thanks for the clarification.

Junio C Hamano· Oct 13, 2025, 17:29 UTC · re: Okhuomon Ajayi · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:

> I’ll revert my local change, run a build and tests, and then think
> about safer alternatives (or leave the NEEDSWORK comment in place if
> changing the hashmap API isn’t appropriate).
> Thanks for the clarification.

If you can convince readers that changing the hashmap API is not appropriate, then I would think that would make a great explanation for a commit that removes the needswork comment without doing anything else. "Thinking about const correctness issues around this code is no longer needed. The hashmap API is right to insist that the extra data pointer must be const because .... Which makes casting constness away when assigning it to opt, which is what the code is, is indeed the only reasonable thing to do, and there is no more change necessary around here." Of course, such a commit log message must fill in the "because ..." part with a convincing argument ;-).

Thanks.

Okhuomon Ajayi· Oct 13, 2025, 18:14 UTC · re: Junio C Hamano · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Hi Junio,

Thanks for explaining! I get it now the NEEDSWORK comment isn’t needed since the hashmap API is supposed to have cmpfn_data as const. I’ve removed the comment and didn’t change anything else

Cheers

On Mon, Oct 13, 2025 at 6:29 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 23 quoted lines

>
> Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:
>
> > I’ll revert my local change, run a build and tests, and then think
> > about safer alternatives (or leave the NEEDSWORK comment in place if
> > changing the hashmap API isn’t appropriate).
> > Thanks for the clarification.
>
> If you can convince readers that changing the hashmap API is not
> appropriate, then I would think that would make a great explanation
> for a commit that removes the needswork comment without doing
> anything else.  "Thinking about const correctness issues around this
> code is no longer needed.  The hashmap API is right to insist that
> the extra data pointer must be const because ....  Which makes
> casting constness away when assigning it to opt, which is what the
> code is, is indeed the only reasonable thing to do, and there is no
> more change necessary around here."  Of course, such a commit log
> message must fill in the "because ..." part with a convincing
> argument ;-).
>
> Thanks.
>
>

Junio C Hamano· Oct 13, 2025, 18:33 UTC · re: Okhuomon Ajayi · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:

> Thanks for explaining! I get it now the NEEDSWORK comment isn’t needed
> since the hashmap API is supposed to have cmpfn_data as const. I’ve
> removed the comment and didn’t change anything else

The NEEDSWORK comment is about going even further, starting from question if hashmap should really be using "const" in the first place, to sort things out among all the components involved (including other users of the hashmap API).

A commit that does not do the necessary study and just removes the needswork comment is simply irresponsible, no?

Okhuomon Ajayi· Oct 13, 2025, 21:55 UTC · re: Junio C Hamano · lore

Re: [PATCH] [Outreachy] patch-ids: fix const correctness

Got it, that helps. I'll take a closer look at how const is handled across the hashmap API before removing the NEEDSWORK comment. Thanks for the guidance!

By the way, I also sent another patch about clarifying the SHA1 usage for patch IDs. Would you mind taking a look when you have a moment?

On Mon, Oct 13, 2025 at 7:33 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

>
> Okhuomon Ajayi <okhuomonajayi54@gmail.com> writes:
>
> > Thanks for explaining! I get it now the NEEDSWORK comment isn’t needed
> > since the hashmap API is supposed to have cmpfn_data as const. I’ve
> > removed the comment and didn’t change anything else
>
> The NEEDSWORK comment is about going even further, starting from
> question if hashmap should really be using "const" in the first
> place, to sort things out among all the components involved
> (including other users of the hashmap API).
>
> A commit that does not do the necessary study and just removes the
> needswork comment is simply irresponsible, no?
>