Re: [PATCH v5 4/9] fetch: print left-hand side when fetching HEAD:foo

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2023 at 02:34:15PM +0200, Patrick Steinhardt wrote:

> @@ -946,7 +948,7 @@ static int update_local_ref(struct ref *ref,
>  	if (oideq(&ref->old_oid, &ref->new_oid)) {
>  		if (verbosity > 0)
>  			display_ref_update(display_state, '=', _("[up to date]"), NULL,
> -					   remote, ref->name, summary_width);
> +					   remote_ref->name, ref->name, summary_width);
>  		return 0;
>  	}

Here (and in other hunks) we now dereference remote_ref unconditionally.
But in existing parts of the code, we guard against remote_ref being
NULL. E.g., later on:

          if (!current || !updated) {
                  const char *msg;
                  const char *what;
                  int r;
                  /*
                   * Nicely describe the new ref we're fetching.
                   * Base this on the remote's ref name, as it's
                   * more likely to follow a standard layout.
                   */
                  const char *name = remote_ref ? remote_ref->name : "";
		  [...]

I'm not sure if the old code was being overly defensive, or if the new
code is ripe for a segfault. But it's probably worth looking into (it
was noticed by Coverity).

Looking at the caller, it is always store_update_refs() which passes its
own "rm", a pointer iterating over ref_map. And it should always be
non-NULL, since that's the loop condition.

So I think your code is fine, but you might want to double-check my
logic. (And it may be worth cleaning up the existing redundant check to
prevent confusion).

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux