Subject: Re: [PATCH 02/19] global: assign non-const strings as required

From: Junio C Hamano <[email-masked]>
Date: Thu, 30 May 2024 12:38:45 -0700

Patrick Steinhardt <[email-masked]> writes:

> Well, we do. Not in `get_fetch_map()`, but in `query_refspecs()`. It
> does weird stuff where it writes the result into either `src` or `dst`
> depending on which of these fields is provided by the caller. Which
> means that one of the fields would typically be a constant, whereas the
> other one will be allocated.

Yes, <src, dst> is used as a pair of <key, value> to query one with
the other (i.e. "where does this one go?" "where does this one come
from?").

But we are not talking about const-ness of the member (iow, once you
point a string with the member, you cannot repoint the pointer to
another string), but we are talking about const-ness of the string
that is pointed by the member (iow, not "char const *src" but "const
char *src"), no?  If I ask "I have this src, where does it go?" with
a refspec element filled with src, the dst member may need to be
updated to point at the string that is the answer of the query, but
that still can be done with "const char *src, *dst", can't it?  That
was what I was wondering.

And again you are conflating "allocated" with "read-write" here.  It
is often convenient if a variable that points at an allocated string
is of type "char *" and not "const char *", because you do not cast
it when calling free().  But if you want to make a structure member
or a variable that holds an allocated string responsible for
_owning_ the piece of memory, then you need to consistently have the
member point at an allocated piece of memory (or NULL), no?  What
this patch does, i.e. prepare an on-stack refspec_str[] array that
is initialized from a constant string, and have .src member point at
it, would not make .src freeable.  In other words, .src pointing at
an allocated piece of string "some of the time" alone is not a good
justification to make it a non-const pointer, I would think.