Junio C Hamano <gits...@pobox.com> writes:

> These three are all updated by the same tree_entry_extract() call,
> and whenever we use mode[12] we use path[12], so if it decides path1
> is used or assigned, it should be able to tell mode1 is, too.
> Unsatisfactory, it surely is...

And immediately after I wrote the above, I am greeted by this:

    gcc (Debian 4.4.5-8) 4.4.5
    match-trees.c:75: error: 'elem1' may be used uninitialized in this function
    match-trees.c:77: error: 'path1' may be used uninitialized in this function

and this crazy one on top squelches it.

If you flip the order of four lines that extracts only when size is
non-zero to extract first from two into elem2, then the warning is
given for elem2/path2 but not for elem1/path1.

I'll initialize all of them to nonsense values for now.

diff --git a/match-trees.c b/match-trees.c
index 4360f10..88981e8 100644
--- a/match-trees.c
+++ b/match-trees.c
@@ -72,9 +72,9 @@ static int score_trees(const unsigned char *hash1, const 
unsigned char *hash2)
                die("%s is not a tree", sha1_to_hex(hash2));
        init_tree_desc(&two, two_buf, size);
        while (one.size || two.size) {
-               const unsigned char *elem1;
+               const unsigned char *elem1 = NULL;
                const unsigned char *elem2;
-               const char *path1;
+               const char *path1 = NULL;
                const char *path2;
                unsigned mode1 = 0; /* make gcc happy */
                unsigned mode2 = 0; /* make gcc happy */
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

Reply via email to