[PATCH] progress: don't dereference before checking for NULL

[PATCH] progress: don't dereference before checking for NULL

[Martin Ågren]

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@gmail.com>
---
 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

Re: [PATCH] progress: don't dereference before checking for NULL

[Eric Sunshine]

On Mon, Aug 10, 2020 at 3:48 PM Martin Ågren <martin.agren@gmail.com> 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@gmail.com>
> ---
> 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).

Re: [PATCH] progress: don't dereference before checking for NULL

[Junio C Hamano]

Martin Ågren <martin.agren@gmail.com> writes:

> 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.

True, true.

Thanks.

Re: [PATCH] progress: don't dereference before checking for NULL

[Martin Ågren]

On Mon, 10 Aug 2020 at 23:27, Eric Sunshine <sunshine@sunshineco.com> wrote:
>
> On Mon, Aug 10, 2020 at 3:48 PM Martin Ågren <martin.agren@gmail.com> wrote:
> >  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.

I'm not a big fan of undefined behavior. In general, I don't buy the
"but in practice it will do what we want" argumentation.

Before 98a1364740 ("trace2: log progress time and throughput",
2020-05-12), we didn't check for NULL in this function. Then that commit
tried to do so. It would feel wrong for me to say "that commit didn't
get it quite right -- rip out the check". Then, to be honest, I'd much
rather just leave it in place. At least that way, someone else might
spot it a year from now.

I could add an early return (instead of an early BUG). That would
gracefully handle NULL. Grepping around suggests there are other `if (!p)
BUG();`. Even Documentation/CodingGuidelines BUGs on a NULL-pointer,
although in the context of checking for NULL (as opposed to "how to
BUG").

> > -       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).

I started with this, but then I felt terrible for just sweeping the
whole thing under the rug.

Martin

Re: [PATCH] progress: don't dereference before checking for NULL

[Taylor Blau]

On Tue, Aug 11, 2020 at 06:28:30AM +0200, Martin Ågren wrote:
> On Mon, 10 Aug 2020 at 23:27, Eric Sunshine <sunshine@sunshineco.com> wrote:
> >
> > On Mon, Aug 10, 2020 at 3:48 PM Martin Ågren <martin.agren@gmail.com> wrote:
> > >  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.
>
> I'm not a big fan of undefined behavior. In general, I don't buy the
> "but in practice it will do what we want" argumentation.

I think that this is good reasoning; having the guard around
'p_progress' being non-NULL makes the implementation have no undefined
behavior, which is worth a lot.

> Before 98a1364740 ("trace2: log progress time and throughput",
> 2020-05-12), we didn't check for NULL in this function. Then that commit
> tried to do so. It would feel wrong for me to say "that commit didn't
> get it quite right -- rip out the check". Then, to be honest, I'd much
> rather just leave it in place. At least that way, someone else might
> spot it a year from now.
>
> I could add an early return (instead of an early BUG). That would
> gracefully handle NULL. Grepping around suggests there are other `if (!p)
> BUG();`. Even Documentation/CodingGuidelines BUGs on a NULL-pointer,
> although in the context of checking for NULL (as opposed to "how to
> BUG").
>
> > > -       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).
>
> I started with this, but then I felt terrible for just sweeping the
> whole thing under the rug.

Yep, I'm a fan of the direction you ended up taking. Thanks.

  Reviewed-by: Taylor Blau <me@ttaylorr.com>

> Martin

Thanks,
Taylor