Thread: gcc4's uninitialized-variable warnings

gcc4's uninitialized-variable warnings

From
Tom Lane
Date:
I asked some gcc experts at Red Hat about the new variable-may-be-used-
uninitialized warnings that gcc 4.x reports.  These occur in cases
like
int    i, j;...foo(&i, &j);// use i and j

I had thought that gcc was being stricter about the possibility that the
called function might not set its output parameters, but the true story
is entirely different.  There's been no change in the strictness of the
check for external function calls.  What is happening is that if foo()
is static and gcc chooses to inline it into the calling function, you
will now see a warning if the transformed code fails the check.  In
essence this means that there is a code path through foo() that doesn't
set the output parameter.

Armed with that knowledge, we can fix these warnings by ensuring the
callee sets the output parameters in all code paths; which is often
cleaner than having the caller initialize the variables before call,
as I was afraid we'd have to do.

I'll work on cleaning these up.
        regards, tom lane


Re: gcc4's uninitialized-variable warnings

From
Bruce Momjian
Date:
Tom Lane wrote:
> I asked some gcc experts at Red Hat about the new variable-may-be-used-
> uninitialized warnings that gcc 4.x reports.  These occur in cases
> like
> 
>     int    i, j;
>     ...
>     foo(&i, &j);
>     // use i and j
> 
> I had thought that gcc was being stricter about the possibility that the
> called function might not set its output parameters, but the true story
> is entirely different.  There's been no change in the strictness of the
> check for external function calls.  What is happening is that if foo()
> is static and gcc chooses to inline it into the calling function, you
> will now see a warning if the transformed code fails the check.  In
> essence this means that there is a code path through foo() that doesn't
> set the output parameter.
> 
> Armed with that knowledge, we can fix these warnings by ensuring the
> callee sets the output parameters in all code paths; which is often
> cleaner than having the caller initialize the variables before call,
> as I was afraid we'd have to do.
> 
> I'll work on cleaning these up.

Wow, that is a nifty complier check.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073