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> --- progress.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/progress.c b/progress.c index 3eda914518..31014e6fca 100644 --- 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); - if (p_progress && *p_progress) { + if (*p_progress) { trace2_data_intmax("progress", the_repository, "total_objects", (*p_progress)->total); @@ -338,7 +341,12 @@ void stop_progress(struct progress **p_progress) void stop_progress_msg(struct progress **p_progress, const char *msg) { - struct progress *progress = *p_progress; + struct progress *progress; + + if (!p_progress) + BUG("don't provide NULL to stop_progress_msg"); + + progress = *p_progress; if (!progress) return; *p_progress = NULL; -- 2.28.0.220.ged08abb693