Silencing the remaining clang 15 warnings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Silencing the remaining clang 15 warnings
Date: 2022-09-19 19:20:43
Message-ID: 514615.1663615243@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While working on the -Wdeprecated-non-prototype fixups discussed
nearby, I saw that clang 15.0 produces a few other new warnings
(which are also visible in the buildfarm). Pursuant to our
usual policy that we should suppress warnings on compilers likely
to be used for development, here's a patch to silence them.

There are three groups of these:

* With %pure-parser, Bison makes the "yynerrs" variable local
instead of static, and then if you don't use it clang notices
that it's set but never read. There doesn't seem to be a way
to persuade Bison not to emit the variable at all, so here I've
just added "(void) yynerrs;" to the topmost production of each
affected grammar. If anyone has a nicer idea, let's hear it.

* xlog.c's AdvanceXLInsertBuffer has a local variable "npages"
that is only read in the "#ifdef WAL_DEBUG" stanza at the
bottom. Here I've done the rather ugly and brute-force thing
of wrapping all the variable's references in "#ifdef WAL_DEBUG".
(I tried marking it PG_USED_FOR_ASSERTS_ONLY, but oddly that
did not silence the warning.) I kind of wonder how useful this
function's WAL_DEBUG output is --- maybe just dropping that
altogether would be better?

* array_typanalyze.c's compute_array_stats counts the number
of null arrays in the column, but then does nothing with the
result. AFAICS this is redundant with what std_compute_stats
will do, so I just removed the variable.

Any thoughts?

regards, tom lane

Attachment Content-Type Size
silence-clang-15-warnings.patch text/x-diff 2.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Koval 2022-09-19 19:26:28 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Previous Message Robert Haas 2022-09-19 18:42:48 Re: has_privs_of_role vs. is_member_of_role, redux