Re: [PATCH 03/19] global: convert intentionally-leaking config strings to consts
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 30, 2024, 16:00 UTC
- Message-ID
- <xmqqfrtzqog5.fsf@gitster.g>
- In-Reply-To
- <ZlhjRtRwxlnchOaV@tanuki>
Patrick Steinhardt <ps@pks.im> writes:
Show 30 quoted lines
> On Wed, May 29, 2024 at 10:28:05AM -0700, Junio C Hamano wrote: >> Patrick Steinhardt <ps@pks.im> 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?