Skip site navigation (1) Skip section navigation (2)

Re: gcc 4.6 warnings -Wunused-but-set-variable

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: gcc 4.6 warnings -Wunused-but-set-variable
Date: 2011-03-30 14:57:30
Message-ID: AANLkTimmU7K6pPmKrE7mq00FxeUx0PL0sbLWmYuw0=vy@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Mar 29, 2011 at 4:48 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> As you might have heard, GCC 4.6 was released the other day.  It
> generates a bunch of new warnings with the PostgreSQL source code, most
> of which belong to the new warning scenario -Wunused-but-set-variable,
> which is included in -Wall.
>
> Attached is a patch that gets rid of most of these.  As you can see,
> most of these remove real leftover garbage.  The line I marked in
> pg_basebackup.c might be an actual problem: It goes through a whole lot
> to figure out the timeline and then doesn't do anything with it.  In
> some other cases, however, one might argue that the changes lose some
> clarity, such as when dropping the return value of strtoul() or
> va_arg().  How should we proceed?  In any case, my patch should be
> re-reviewed for any possible side effects that I might have hastily
> removed.

In the case of variable.c, it is entirely unclear that there's any
point in calling strtoul() at all.  Maybe we should just remove that
and the following Assert() as well.

In parse_utilcmd.c, do we need to look up the collation OID if we're
just discarding it anyway?

In the case of the va_arg() calls, maybe something like /* advance arg
position, but ignore result */?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-03-30 14:57:32
Subject: Re: Problem with pg_upgrade?
Previous:From: Greg StarkDate: 2011-03-30 14:40:11
Subject: Re: Process local hint bit cache

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group