Re: /* compiler workaround */ - what was the issue?

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2016, 18:54 UTC
Message-ID: <xmqq60ur3tlu.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <572CDCFF.9050607@ramsayjones.plus.com>

Ramsay Jones <ramsay@ramsayjones.plus.com> writes:

Show 6 quoted lines

> The patch below applies to master (I haven't checked for any more
> additions).
>
>  	if (bisect_list) {
> -		int reaches = reaches, all = all;
> +		int reaches = 0, all = 0;

One thing that is somewhat sad is that this makes future readers wonder if these values '0' are sensible initial values.

Having to wonder "is it sensible to initialize this variable to 0? Shouldn't it be initialized to INT_MAX instead?" is wasting their time exactly because we _know_ these are not even "initial values". We know these do not have to be initialized, because some more appropriate values will get assigned to them before they are used, and have these only because some compilers get it wrong.

The original "reaches = reaches" had the documentation value (at least for those who knew the convention) to save the readers from wasting their time that way. Now these 0 are indistinguishable from the other initializations that require to be zero.

Show 10 quoted lines

> diff --git a/read-cache.c b/read-cache.c
> index d9fb78b..978d6b6 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1870,7 +1870,7 @@ static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce,
>  {
>  	int size;
>  	struct ondisk_cache_entry *ondisk;
> -	int saved_namelen = saved_namelen; /* compiler workaround */
> +	int saved_namelen = 0;

I wonder if can we come up with a short and sweet notation to remind futhre readers that this "initialization" is not initializing but merely squelching warnings from stupid compilers, and agree to use it consistently?