silence GCC4 warning

Neil Conway <neilc@samurai.com> writes:

This patch silences a GCC 4.0 warning about a potentially-uninitialized
variable in pl_comp.c,

AFAICT, gcc4's default behavior is to warn about

int foo;

somefunc(&foo);

which unfortunately is a very common usage that I'm not real thrilled
about having to fix every occurrence of. I've been meaning to look into
whether they provided a pragma or something to mark function parameters
as output-only, so that this message could be suppressed where
appropriate without adding a lot of useless initializations.

In the meantime, I don't see the point of patching just one place.

regards, tom lane

Tom Lane wrote:

AFAICT, gcc4's default behavior is to warn about

int foo;

somefunc(&foo);

A simple test shows that this is not the case, even with lots of -W
options.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

A simple test shows that this is not the case, even with lots of -W
options.

Right -- AFAICS we only get the following warnings of this class with
GCC 4.0 on current sources:

% gcc --version
gcc-4.0 (GCC) 4.0.1 20050701 (prerelease) (Debian 4.0.0-12)
[...]
% make -s clean all
[...]
In file included from /home/neilc/pgsql/src/backend/regex/regexec.c:1070:
/home/neilc/pgsql/src/backend/regex/rege_dfa.c: In function 'getvacant':
/home/neilc/pgsql/src/backend/regex/rege_dfa.c:581: warning: 'lastap.ss'
may be used uninitialized in this function
/home/neilc/pgsql/src/backend/regex/rege_dfa.c:581: warning: 'lastap.co'
may be used uninitialized in this function

/home/neilc/pgsql/src/backend/utils/adt/inet_net_ntop.c: In function
'inet_net_ntop_ipv6':
/home/neilc/pgsql/src/backend/utils/adt/inet_net_ntop.c:427: warning:
'cur.len' may be used uninitialized in this function
/home/neilc/pgsql/src/backend/utils/adt/inet_net_ntop.c:427: warning:
'best.len' may be used uninitialized in this function

/home/neilc/pgsql/src/interfaces/ecpg/pgtypeslib/datetime.c: In function
'PGTYPESdate_defmt_asc':
/home/neilc/pgsql/src/interfaces/ecpg/pgtypeslib/datetime.c:335:
warning: 'tm.tm_mday' may be used uninitialized in this function
/home/neilc/pgsql/src/interfaces/ecpg/pgtypeslib/datetime.c:335:
warning: 'tm.tm_mon' may be used uninitialized in this function
/home/neilc/pgsql/src/interfaces/ecpg/pgtypeslib/datetime.c:335:
warning: 'tm.tm_year' may be used uninitialized in this function

/home/neilc/pgsql/src/pl/plpgsql/src/pl_comp.c: In function
'plpgsql_parse_tripwordtype':
/home/neilc/pgsql/src/pl/plpgsql/src/pl_comp.c:1372: warning: 'cp[0]'
may be used uninitialized in this function
/home/neilc/pgsql/src/pl/plpgsql/src/pl_comp.c:1372: warning: 'cp[1]'
may be used uninitialized in this function

(Plus many errors regarding signedness, which is a separate matter.)

All these warnings like somewhat reasonable, AFAICS: while the code may
actually always initialize the variables before using them, it's
understandable that the compiler can't infer this automatically. And
this is surely a tiny fraction of the changes that would be required if
something as fundamental as initialization via out parameters was broken.

-Neil

Neil Conway <neilc@samurai.com> writes:

Peter Eisentraut wrote:

A simple test shows that this is not the case, even with lots of -W
options.

Right -- AFAICS we only get the following warnings of this class with
GCC 4.0 on current sources:

Hmm ... my comments were based on experiments with a prerelease gcc4
that was circulating inside Red Hat; IIRC it showed some hundreds of
warnings of this type on the PG sources :-(. It sounds like they've
improved it somewhat, but I'm still not clear on what it is warning
about that prior releases did not.

regards, tom lane