On Mon, Aug 10, 2020 at 3:48 PM Martin Ågren <martin.agren@xxxxxxxxx> wrote:
> In `stop_progress()`, we're careful to check that `p_progress` is
> non-NULL before we dereference it, but by then we have already
> dereferenced it when calling `finish_if_sparse(*p_progress)`. And, for
> what it's worth, we'll go on to blindly dereference it again inside
> `stop_progress_msg()`.
>
> We could return early if we get a NULL-pointer, but let's go one step
> further and BUG instead. The progress API handles NULL just fine, but
> that's the NULL-ness of `*p_progress`, e.g., when running with
> `--no-progress`. If `p_progress` is NULL, chances are that's a mistake.
> For symmetry, let's do the same check in `stop_progress_msg()`, too.
>
> Signed-off-by: Martin Ågren <martin.agren@xxxxxxxxx>
> ---
> diff --git a/progress.c b/progress.c
> @@ -319,9 +319,12 @@ static void finish_if_sparse(struct progress *progress)
> void stop_progress(struct progress **p_progress)
> {
> + if (!p_progress)
> + BUG("don't provide NULL to stop_progress");
> +
> finish_if_sparse(*p_progress);
I'm wondering what this really buys us over simply crashing due to the
NULL dereference (aside from the slightly more informative diagnostic
message). Either way, it's going to crash, as it should because
passing NULL is indeed a programmer error for these two functions. I'm
pretty sure that it is more common in this project simply to allow a
programmer error like this simply to crash on its own rather than
adding code to make it crash explicitly.
> - if (p_progress && *p_progress) {
> + if (*p_progress) {
In other words, I think the entire patch can be reduced to just this
change here (and a simplified commit message).
