All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@grubix.eu>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/6] do not discard const: keep signature
Date: Thu, 26 Mar 2026 10:18:52 -0700	[thread overview]
Message-ID: <xmqqbjgaqzk3.fsf@gitster.g> (raw)
In-Reply-To: <9a90f93111ec54e5eb9675cb84ac1d70ad95e118.1774537954.git.git@grubix.eu> (Michael J. Gruber's message of "Thu, 26 Mar 2026 16:22:51 +0100")

Michael J Gruber <git@grubix.eu> writes:

> Here, while we do not mutate the struct itself, many other signatures
> expect a non-const argument - possibly unnecessarily - so we opt to keep
> the original signature by casting to non-const.
> ---

Sorry, but I do not understand the above description, or the code
change.  Doesn't bsearch() returns non-const "void *" pointer?

Ah, the constness of the return value in C23 depends on the
constness of pm->commits[] array, which inherits its constness from
the constness of parameter pm to the function, and you cast the
value we are going to return explicitly to a non-const pointer.

OK.  In the context of "C23 constness" patch series, that may be
obvious to you, but I suspect a future reader who finds this single
commit from the output of "git blame" or something would be puzzled
unless we say this is about adjusting to C23 that makes bsearch() a
qualifier-preserving function somewhere in the log message.


>  pseudo-merge.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pseudo-merge.c b/pseudo-merge.c
> index a2d5bd85f9..ac81792e65 100644
> --- a/pseudo-merge.c
> +++ b/pseudo-merge.c
> @@ -644,7 +644,7 @@ static struct pseudo_merge_commit *find_pseudo_merge(const struct pseudo_merge_m
>  	if (!pm->commits_nr)
>  		return NULL;
>  
> -	return bsearch(&pos, pm->commits, pm->commits_nr,
> +	return (struct pseudo_merge_commit *) bsearch(&pos, pm->commits, pm->commits_nr,
>  		       PSEUDO_MERGE_COMMIT_RAWSZ, pseudo_merge_commit_cmp);
>  }

  reply	other threads:[~2026-03-26 17:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 15:22 [PATCH 0/6] ISOC23: quell warnings on discarding const Michael J Gruber
2026-03-26 15:22 ` [PATCH 1/6] do not discard const: the simple cases Michael J Gruber
2026-03-26 17:34   ` Jeff King
2026-03-26 17:45     ` Junio C Hamano
2026-03-26 19:23       ` [PATCH] config: store allocated string in non-const pointer Jeff King
2026-03-26 15:22 ` [PATCH 2/6] do not discard const: make git-compat-util ISOC23-like Michael J Gruber
2026-03-26 15:22 ` [PATCH 3/6] do not discard const: adjust to non-const data types Michael J Gruber
2026-03-26 17:28   ` Junio C Hamano
2026-03-26 15:22 ` [PATCH 4/6] do not discard const: declare const where we stay const Michael J Gruber
2026-03-26 15:22 ` [PATCH 5/6] do not discard const: keep signature Michael J Gruber
2026-03-26 17:18   ` Junio C Hamano [this message]
2026-03-26 15:22 ` [PATCH 6/6] do not discard const: the ugly truth Michael J Gruber
2026-03-26 17:07   ` Junio C Hamano
2026-03-26 17:42   ` Jeff King
2026-03-26 19:02     ` [PATCH 0/4] fix const issues in revision parser Jeff King
2026-03-26 19:04       ` [PATCH 1/4] revision: make handle_dotdot() interface less confusing Jeff King
2026-03-26 19:28         ` Junio C Hamano
2026-03-26 23:14           ` Jeff King
2026-03-27 15:55             ` Junio C Hamano
2026-03-26 19:05       ` [PATCH 2/4] rev-parse: simplify dotdot parsing Jeff King
2026-03-26 19:13       ` [PATCH 3/4] revision: avoid writing to const string for parent marks Jeff King
2026-03-26 19:14       ` [PATCH 4/4] rev-parse: " Jeff King
2026-03-26 16:26 ` [PATCH 0/6] ISOC23: quell warnings on discarding const D. Ben Knoble
2026-03-27 17:45   ` Michael J Gruber

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=xmqqbjgaqzk3.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.