From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | gcc4's uninitialized-variable warnings |
Date: | 2005-09-24 21:03:44 |
Message-ID: | 23625.1127595824@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-09-24 21:19:47 | Re: 64-bit API for large objects |
Previous Message | Jeremy Drake | 2005-09-24 20:00:10 | Re: 64-bit API for large objects |