On Wed, Feb 10 2021, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Fri, 5 Feb 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> Add a diff_free() function to free anything we may have allocated in
>> the "diff_options" struct, and the ability to make calling it a noop
>> by setting "no_free" in "diff_options".
>
> Why do we need a `no_free` flag? Why not simply set the `free()`d (or
> `fclose()`d) attributes to `NULL`?
Because we're calling the diff API N times, so we need to not have those
be NULL while we're using them in a loop, and we need to not free()
them, and then flip "no_free = 0" at the end and free() them.
>> diff --git a/builtin/add.c b/builtin/add.c
>> index a825887c50..6319710186 100644
>> --- a/builtin/add.c
>> +++ b/builtin/add.c
>> @@ -282,7 +282,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix)
>> if (out < 0)
>> die(_("Could not open '%s' for writing."), file);
>> rev.diffopt.file = xfdopen(out, "w");
>> - rev.diffopt.close_file = 1;
>> + rev.diffopt.fclose_file = 1;
>
> This rename makes the patch unnecessarily tedious to review, and I do not
> even agree with leaking the implementation detail that we need to
> `fclose()` the file.
>
> Let's just not?
Fair enough, I figured it would be easier for reviewers to reason about
to be guaranteed to see all the uses of the flag, but I'll drop it.
>> @@ -6399,10 +6399,10 @@ void diff_flush(struct diff_options *options)
>> * options->file to /dev/null should be safe, because we
>> * aren't supposed to produce any output anyway.
>> */
>> - if (options->close_file)
>> + if (options->fclose_file)
>> fclose(options->file);
>
> And at this stage, we should set `options->file = NULL`.
Sure, why not, but unless we get rid of the need for "close_file"
there's not much point other than ease of inspection in a
debugger...[cont].
>> [...]
>> +void diff_free(struct diff_options *options)
>> +{
>> + if (options->no_free)
>> + return;
>> + if (options->fclose_file)
>> + fclose(options->file);
>
> And at this stage, we should set `options->file = NULL`.
...ditto...[cont]
>> +}
>> +
>> +
>> static int match_filter(const struct diff_options *options, const struct diff_filepair *p)
>> {
>> return (((p->status == DIFF_STATUS_MODIFIED) &&
>> diff --git a/diff.h b/diff.h
>> index 2ff2b1c7f2..d1d74c3a9e 100644
>> --- a/diff.h
>> +++ b/diff.h
>> @@ -49,7 +49,16 @@
>> * - Once you finish feeding the pairs of files, call `diffcore_std()`.
>> * This will tell the diffcore library to go ahead and do its work.
>> *
>> + * - The `diff_opt_parse()` etc. functions might allocate memory in
>> + * `struct diff_options`. When running the API `N > 1` set `.no_free
>> + * = 1` to make the `diff_free()` invoked by `diff_flush()` below a
>> + * noop.
>
> I have serious trouble parsing that last sentence. Would you mind
> rephrasing it?
Willdo.
>> + *
>> * - Calling `diff_flush()` will produce the output.
>> + *
>> + * - If you set `.no_free = 1` before set it to `0` and call
>> + * `diff_free()` again. If `.no_free = 1` was not set there's no
>> + * need to call `diff_free()`, `diff_flush()` will call it.
>
> Again, as I mentioned before, the indicator whether things need to be
> released should be whether the attribute is `NULL` or not. And once
> released, ot should be set to `NULL`.
>
> Other than that, it looks fine to me. And I definitely like the idea of
> introducing a function to release all of the stuff in `struct diffopt`.
[cont]...I don't think it's possible in anything like the current API to
do that.
We don't want to "if (file) fclose(file)", instead we need an opt-in "if
(close_file) fclose(file)". That's because usually the "file" is
stdout. So close_file=1 is only set when we're opening a "real" file,
/dev/null or whatever.
That along with the "no_free" flag as noted above means we need both a
"no_free" and "close_file" flags.
Unless there's some way of re-arranging this that I'm missing.
