Thread (2 messages) 2 messages, 2 authors, 2024-05-30

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

From: Patrick Steinhardt <hidden>
Date: 2024-05-30 11:30:20

On Wed, May 29, 2024 at 10:28:05AM -0700, Junio C Hamano wrote:
Patrick Steinhardt [off-list ref] writes:
quoted
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.

Patrick

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help