Junio C Hamano <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
