Re: [COMMITTERS] pgsql: Remove dead assignment

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Remove dead assignment
Date: 2012-03-28 16:56:21
Message-ID: 1332953781.14371.5.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On mån, 2012-03-26 at 15:53 -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On mån, 2012-03-26 at 15:15 -0400, Tom Lane wrote:
> >> I also do not think it does anything for readability for this call
> >> of read_info() to be unexpectedly unlike all the others.
>
> > I do not think that it is good code quality to assign something to a
> > variable and then assign something different to a variable later in the
> > same function.
>
> Well, that's a totally different issue, because if we had used a
> different variable for the other purpose, this assignment would
> still be dead and coverity would still be whinging about it, no?

Let's look at this differently. If this code were written from scratch
now, it might have turned out like this:

Form_pg_sequence old_seq, seq;

...
old_seq = read_info(elm, seq_rel, &buf);
...
seq = (Form_pg_sequence) GETSTRUCT(tuple);

But that gets a complaint from gcc:

sequence.c:248:19: error: variable ‘old_seq’ set but not used [-Werror=unused-but-set-variable]

So when faced with this, what is the right fix? (Probably not assigning
the useless return value to some other variable used for a different
purpose.)

> The problem that I have with this change (and the similar ones you've
> made elsewhere) is really that it's only chance that the code isn't
> fetching anything from the result of read_info.

What other changes are you referring to? I don't recall any similar
ones and don't find any in the logs.

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2012-03-28 18:14:09 pgsql: Run maintainer-check on all PO files, not only configured ones
Previous Message Robert Haas 2012-03-28 16:24:23 pgsql: Attempt to unbreak pg_test_timing on Windows.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-28 17:46:30 Re: patch for parallel pg_dump
Previous Message Peter Geoghegan 2012-03-28 16:44:58 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)