Jeff King <[email protected]> writes:
> Of the 8 patches, this is the one I find the least satisfying, if only
> because I do not think gcc's failure is because of complicated control
> flow, and rearranging the code would only hurt readability. And I'm
> quite curious why it complains about "mode", but not about the other
> variables, which are set in the exact same place (and why it would not
> be able to handle such a simple control flow at all).
>
> It makes me wonder if I am missing something, or there is some subtle
> bug. But I can't see it. Other eyes appreciated.
I obviously am not qualified as "other eyes" to catch bugs in this
code as this is entirely mine, but I do not see any obvious reason
that would make the compiler to think mode[12] less initialized than
elem[12] or path[12] either.
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...
> match-trees.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/match-trees.c b/match-trees.c
> index 26f7ed1..4360f10 100644
> --- a/match-trees.c
> +++ b/match-trees.c
> @@ -71,13 +71,13 @@ static int score_trees(const unsigned char *hash1, const
> unsigned char *hash2)
> if (type != OBJ_TREE)
> 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 = elem1;
> - const unsigned char *elem2 = elem2;
> - const char *path1 = path1;
> - const char *path2 = path2;
> - unsigned mode1 = mode1;
> - unsigned mode2 = mode2;
> + while (one.size || two.size) {
> + const unsigned char *elem1;
> + const unsigned char *elem2;
> + const char *path1;
> + const char *path2;
> + unsigned mode1 = 0; /* make gcc happy */
> + unsigned mode2 = 0; /* make gcc happy */
> int cmp;
>
> if (one.size)
--
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
