On Sat, Mar 23, 2013 at 09:55:53PM -0700, Junio C Hamano wrote:
> René Scharfe <rene.scha...@lsrfire.ath.cx> writes:
>
> > Hmm, let's see if we can help the compiler follow the code without
> > making it harder for people to understand. The patch looks a bit
> > jumbled, but the resulting code is OK in my biased opinion.
>
> I actually think the result is much better than a mere "OK"; the
> duplicated "at this point we know path1 (or path2) is missing from
> the other side" has been bothering me and I was about to suggest a
> similar rewrite before I read your message ;-)
>
> However, the same compiler still thinks {elem,path,mode}1 can be
> used uninitialized (but not {elem,path,mode}2). The craziness I
> reported in the previous message is also the same. With this patch
> on top to swap the side we inspect first, the compiler thinks
> {elem,path,mode}2 can be used uninitialized but not the other three
> variables X-<.
Yeah, I'd agree that the result is more readable, but it does not
address the original problem. Junio, do you want to drop my patch,
squash the initialization of mode into René's version, and just add a
note to the commit message that we still have to deal with the gcc
warning?
-Peff
--
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
