Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit. - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Date
Msg-id 1297975653.2226.2255.camel@ebony
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
List pgsql-hackers
On Thu, 2011-02-17 at 10:09 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Thu, 2011-02-17 at 00:53 +0000, Tom Lane wrote:
> >> Doesn't anybody around here pay attention to compiler warnings?
> 
> > If you see one, then I accept one was there. I didn't see one, and a
> > full make distclean and re-compile doesn't show a compiler warning for
> > that either. So I guess I'm doing something wrong, on this platform:
> 
> > I'm using Ubuntu 10.04 LTS, with commands for development:
> > ./configure --enable-cassert --enable-depend --enable-debug
> > make -j4
> 
> Hmm ... the only plausible reason I can think of for gcc not showing
> that warning would be building with -O0 (which disables the flow graph
> computations needed to detect uses of uninitialized values).  Your
> configure command doesn't betray any such thing, but maybe you've got
> some CFLAGS overrides you're not showing us?
> 
> I usually find that -O1 is the best compromise setting for development
> builds.  It enables uninitialized-variable warnings but doesn't produce
> code that's completely unfriendly to gdb.  (Sometimes I do recompile a
> specific file at -O0 if it's making no sense during single-stepping.)

Just recompiled with explicit CFLAGS=-O1 using my distro's gcc 4.4.3

The only difference in messages I got was

dbsize.c: In function ‘pg_relation_filepath’:
dbsize.c:570: warning: ‘rnode.dbNode’ may be used uninitialized in this
function
dbsize.c:570: warning: ‘rnode.spcNode’ may be used uninitialized in this
function

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Rewrite, normal execution vs. EXPLAIN ANALYZE
Next
From: Bruce Momjian
Date:
Subject: Re: Coding style guide