Re: To "const char *" and cast on free(), or "char *" and no cast...
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 14, 2021, 20:22 UTC
- Message-ID
- <xmqqlf2vbbl8.fsf@gitster.g>
- In-Reply-To
- <87mtnbfk0g.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 16 quoted lines
>> It's great to see these leaks being fixed. I wonder though if it would >> be better to change the structure definition so that 'name' and 'path' >> are no longer 'const'. That would be a better reflection of the new >> regime.[...] > > I think this is the right thing to do, but I'm not quite sure. There was > a thread at it here: > > https://lore.kernel.org/git/YUZG0D5ayEWd7MLP@carlos-mbp.lan/ > > Where I chimed in and suggested exactly what you're saying here, but the > consensus seemed to go the other way, and if you grep: > > git grep -F 'free((char *)' > > You can see that we use this pattern pretty widely.
Unfortunately, we probably need to make a trade-off and cannot eat the cake and have it at the same time.
If we leave the .members non-const, the destructor may have to cast the constness away. If it is marked const * const, then we also need to let the constructor do the same.
By marking the .members const, we can be sure that the users of the API will not muck with the values once the structure is instanciated and given to them, but the destructor need to cast the constness away. It may be lessor of two evils, as the need to cast is isolated in the _implementation_ of the API, and casts in the _users_ of the API would stand out more.