From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Compiler warning in costsize.c |
Date: | 2017-04-10 07:13:45 |
Message-ID: | CAKJS1f--+VWES_uMfAbuH4L5HnDPGBVTROuC7DUv=g9zzCu9-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 April 2017 at 04:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'd be happier with something along the line of
>
> RangeTblEntry *rte;
> ListCell *lc;
>
> /* Should only be applied to base relations that are subqueries */
> Assert(rel->relid > 0);
> rte = planner_rt_fetch(rel->relid, root);
> #ifdef USE_ASSERT_CHECKING
> Assert(rte->rtekind == RTE_SUBQUERY);
> #else
> (void) rte; /* silence unreferenced-variable complaints */
> #endif
the (void) rte; would not be required to silence MSVC here. Of course,
PG_USED_FOR_ASSERTS_ONLY would be required to stop some smarter
compiler from complaining.
> assuming that that actually does silence the warning on MSVC.
>
> BTW, is it really true that only these two places produce such warnings
> on MSVC? I see about three dozen uses of PG_USED_FOR_ASSERTS_ONLY in our
> tree, and I'd have expected all of those places to be causing warnings on
> a compiler that doesn't have a way to understand that annotation.
Seems that MSVC is happy once the variable is assigned, and does not
bother checking if the variable is used after being assigned, whereas,
some other compilers might see the variable as uselessly assigned.
At the moment there are no other warnings from MSVC since all the
other places the variable gets assigned a value in some code path.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-04-10 07:26:11 | Should pg_current_wal_location() become pg_current_wal_lsn() |
Previous Message | Ashutosh Bapat | 2017-04-10 07:11:25 | Re: Partition-wise join for join between (declaratively) partitioned tables |