Subject: Re: [PATCH 03/19] global: convert intentionally-leaking config strings to consts

From: Junio C Hamano <[email-masked]>
Date: Thu, 30 May 2024 09:00:58 -0700

Patrick Steinhardt <[email-masked]> writes:

> On Wed, May 29, 2024 at 10:28:05AM -0700, Junio C Hamano wrote:
>> Patrick Steinhardt <[email-masked]> writes:
>> 
>> > There are multiple cases where we intentionally leak config strings:
>> >
>> >   - `struct gpg_format` is used to track programs that can be used for
>> >     signing commits, either via gpg(1), gpgsm(1) or ssh-keygen(1). The
>> >     user can override the commands via several config variables. As the
>> >     array is populated once, only, and will never be free'd, it is fine
>> >     to treat the program as a quasi-constant.
>> >
>> >   - `struct ll_merge_driver` is used to track merge drivers. Same as
>> >     with the GPG format, these drivers are populated once and then
>> >     reused. Its data is never free'd, either.
>> >
>> >   - `struct userdiff_funcname` and `struct userdiff_driver` can be
>> >     configured via `diff.<driver>.*` to add additional drivers. Again,
>> >     these have a global lifetime and are never free'd.
>> >
>> > All of these are intentionally kept alive and never free'd. Let's mark
>> > the respective fields as `const char *` and cast away the constness when
>> > assigning those values.
>> 
>> It is not unclear where the linkage between "not freed" and "must be
>> const" comes from.  What am I missing?
>
> It comes from `-Wwrite-strings`, which will mark string constants as
> `const char *`. This will cause warnings in all of the above cases
> because the fields are being assigned constants, but those fields are
> currently `char *`. Will clarify.

In short, these warnings have nothing to do with the pointee by
these variables or struct members are eventually freed or not, no?