[PATCH] column.c: Fix an "variable might be used uninitialized" warning

[PATCH] column.c: Fix an "variable might be used uninitialized" warning

[Ramsay Jones]

In particular, gcc complains as follows:

        CC column.o
    column.c: In function 'print_columns':
    column.c:305: warning: 'len' may be used uninitialized \
        in this function

The compiler can determine that the 'len' variable, which is
passed by reference to the largest_block() function, may indeed
not be set. For example, if largest_block() returns zero, then
the 'len' output parameter will not be assigned to, which would
result in the local 'len' variable remaining uninitialised.
This would not lead to 'len' actually being used, however, since
the code checks for this case ('size' will be set to zero) and
will not execute the remainder of the loop body.

In order to suppress the warning, we simply initialise the 'len'
variable to zero.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---

Hi Nguyen,

Could you please squash this into the relevant commit in your
nd/column series. Thanks!

[gcc v4.1.2 (on Linux) complains, but gcc v3.4.4 and gcc v4.4.0
do *not* complain.]

ATB,
Ramsay Jones

 column.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/column.c b/column.c
index 8214a9b..80183ea 100644
--- a/column.c
+++ b/column.c
@@ -302,7 +302,7 @@ static struct area *find_large_blocks(const struct string_list *list, int *nr_p)
 	memset(&last, 0, sizeof(last));
 
 	for (i = 0; i < list->nr; i++) {
-		int len, size = largest_block(list, i, 0, &len);
+		int len = 0, size = largest_block(list, i, 0, &len);
 		if (!size || len == 1)
 			continue;
 		/* the new found area is overlapped with the old one,
-- 
1.7.9