From: Junio C Hamano <gitster@pobox.com>
To: Michael J Gruber <git@grubix.eu>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/6] do not discard const: the ugly truth
Date: Thu, 26 Mar 2026 10:07:59 -0700 [thread overview]
Message-ID: <xmqqfr5mr028.fsf@gitster.g> (raw)
In-Reply-To: <fe9c86af4825a81b2618ae8ffc8be12300058af2.1774537954.git.git@grubix.eu> (Michael J. Gruber's message of "Thu, 26 Mar 2026 16:22:52 +0100")
Michael J Gruber <git@grubix.eu> writes:
> ISOC23 reveals that we mutate argv strings in place. Confess to this
> with explicit casts.
> ---
> builtin/rev-parse.c | 8 ++++----
> revision.c | 8 ++++----
> 2 files changed, 8 insertions(+), 8 deletions(-)
Forgot to sign-off?
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index 01a62800e8..f429793b6f 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -265,7 +265,7 @@ static int show_file(const char *arg, int output_prefix)
> return 0;
> }
>
> -static int try_difference(const char *arg)
> +static int try_difference(char *arg)
> {
> char *dotdot;
> struct object_id start_oid;
> @@ -325,7 +325,7 @@ static int try_difference(const char *arg)
> return 0;
> }
This one is unfortunate in that in the end the incoming arg is
temporarily truncated by substituting the first "." in the ".."
found in the string with "\0", and then restored to the original
value before returning to the caller, so unless the caller is
handing a piece of memory in a read-only segment, nobody should
hurt or even notice.
> -static int try_parent_shorthands(const char *arg)
> +static int try_parent_shorthands(char *arg)
> {
> char *dotdot;
> struct object_id oid;
> @@ -1145,9 +1145,9 @@ int cmd_rev_parse(int argc,
> }
>
> /* Not a flag argument */
> - if (try_difference(arg))
> + if (try_difference((char *) arg))
> continue;
> - if (try_parent_shorthands(arg))
> + if (try_parent_shorthands((char *) arg))
> continue;
> name = arg;
> type = NORMAL;
The same, with "^" in magic sequences "^!", "^@", and "^-".
> diff --git a/revision.c b/revision.c
> index 31808e3df0..a28b14a2ea 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2132,7 +2132,7 @@ static int handle_dotdot(const char *arg,
> int cant_be_filename)
> {
> struct object_context a_oc = {0}, b_oc = {0};
> - char *dotdot = strstr(arg, "..");
> + char *dotdot = (char *) strstr(arg, "..");
> int ret;
>
> if (!dotdot)
The patch takes a different strategy to deal with this one, even
though the pattern should be exactly the same as try_difference() we
saw earlier. Shouldn't we take the same "internally we know we muck
with the string temporarily, but externally we pretend that we take
a const pointer because we revert our temporary modification"
approach in builtin/rev-parse.c too?
One thing that _could_ break if we did so is when the callers do
pass a string in read-only segment to these functions, trusting the
function signature that takes a const pointer promises them that it
is safe. And to prepare for it, the approach you took in
builtin/rev-parse.c to be honest about it to the callers is safer.
So in that sense, perhaps this function should be updated to take a
non-const pointer to arg instead of sprinkling casts in the body?
> @@ -2176,7 +2176,7 @@ static int handle_revision_arg_1(const char *arg_, struct rev_info *revs, int fl
> goto out;
> }
>
> - mark = strstr(arg, "^@");
> + mark = (char *) strstr(arg, "^@");
> if (mark && !mark[2]) {
> *mark = 0;
> if (add_parents_only(revs, arg, flags, 0)) {
> @@ -2185,13 +2185,13 @@ static int handle_revision_arg_1(const char *arg_, struct rev_info *revs, int fl
> }
> *mark = '^';
> }
> - mark = strstr(arg, "^!");
> + mark = (char *) strstr(arg, "^!");
> if (mark && !mark[2]) {
> *mark = 0;
> if (!add_parents_only(revs, arg, flags ^ (UNINTERESTING | BOTTOM), 0))
> *mark = '^';
> }
> - mark = strstr(arg, "^-");
> + mark = (char *) strstr(arg, "^-");
> if (mark) {
> int exclude_parent = 1;
Ditto.
next prev parent reply other threads:[~2026-03-26 17:08 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
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 [this message]
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=xmqqfr5mr028.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox