Ramsay Jones <ram...@ramsayjones.plus.com> writes:
> 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.
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
