Patrick Steinhardt <ps@xxxxxx> 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.
