All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Michael J Gruber <git@grubix.eu>,  git@vger.kernel.org
Subject: Re: [PATCH 1/4] revision: make handle_dotdot() interface less confusing
Date: Fri, 27 Mar 2026 08:55:18 -0700	[thread overview]
Message-ID: <xmqqv7ehmfmh.fsf@gitster.g> (raw)
In-Reply-To: <20260326231415.GA420281@coredump.intra.peff.net> (Jeff King's message of "Thu, 26 Mar 2026 19:14:15 -0400")

Jeff King <peff@peff.net> writes:

>> And once we accept that it is inevitable to make a copy, everything
>> else falls into the right place.
>
> Yeah, I don't think there is another good option. We can drop the
> "const" from the interface, which would be more honest, but then callers
> that use string literals have to either make their own copy, or cast
> away the constness and pray.
>
> The only "right" solution that avoids copying is if all of the
> lower-level functions learned to work with ptr/len pairs instead of
> NUL-terminated strings. But having done that sort of conversion before,
> it ends up quite messy and is prone to errors. Somebody is welcome to
> try tackling that if they want, but I don't. :)

We would need to call out to a library function or system call
eventually down the callchain, at which point you'd need to somehow
come up with a NUL-terminated equivalent of that <ptr, len> pair.

So I would avoid going down that path, unless the language itself
has already abstracted that difference away, and C is not among
those languages.

  reply	other threads:[~2026-03-27 15:55 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
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 [this message]
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=xmqqv7ehmfmh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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.