On Wed, Mar 09 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> So I'd prefer to keep this part of the general structure as-is, >> i.e. even if we do nothing with "diffopt" *yet* we can assert ... > > Please don't. > > It will become hard to tell during the patch progression if "we can > do so even though we do not need to do so *yet*" is correct > (e.g. diffopt---which does not have a separate allocation to be > released), or if "pretending that the field is cleared by _release() > function is premature and will lead to a new leak" (e.g. if you lost > separate clearing of .prune_data at this step, that would be an > incorrect change because it does hold on to an allocated resource). For a v2 I've rewritten those sorts of changes out. I've bundled them up to a commit for "diffopt" at the end, even though whe don't free() it yet. Depending on what you think of that change we can either drop it or keep it, but in either case it should be obvious what is and isn't in anticipation of any future free() we aren't yet doing.
