gcc4's uninitialized-variable warnings

Started by Tom Laneover 20 years ago2 messageshackers
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

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

#2Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#1)
Re: gcc4's uninitialized-variable warnings

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, Pennsylvania 19073