Re: [PATCH v2 03/18] is_refname_available(): avoid shadowing "dir" variable

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

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

> The function had a "dir" parameter that was shadowed by a local "dir"
> variable within a code block. Use the former in place of the latter.
> (This is consistent with "dir"'s use elsewhere in the function.)
>
> Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
> ---
>  refs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 776bbce..9d87e84 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -967,10 +967,10 @@ static int is_refname_available(const char *refname,
>  		 * "refs/foo/bar/"). It is a problem iff it contains
>  		 * any ref that is not in "skip".
>  		 */
> -		struct ref_entry *entry = dir->entries[pos];
> -		struct ref_dir *dir = get_ref_dir(entry);
>  		struct nonmatching_ref_data data;

Wow, the original is a tricky code, but that helps us be confident
that this change is not breaking anything by "unmasking" the value
of incoming "dir" ;-)

> +		struct ref_entry *entry = dir->entries[pos];
>  
> +		dir = get_ref_dir(entry);
>  		data.skip = skip;
>  		sort_ref_dir(dir);
>  		if (!do_for_each_entry_in_dir(dir, 0, nonmatching_ref_fn, &data))
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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]