On Tue, Sep 20, 2022 at 7:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> * 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.
+1. FTR they know about this:
https://www.mail-archive.com/bison-patches@gnu.org/msg07836.html
https://github.com/akimd/bison/commit/a166d5450e3f47587b98f6005f9f5627dbe21a5b
... but that YY_ATTRIBUTE_UNUSED hasn't landed in my systems'
/usr[/local]/share/bison/skeletons/yacc.c yet and it seems harmless
and also legitimate to reference yynerrs from an action.
> * 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?
No opinion on the value of the message, but maybe
pg_attribute_unused() 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.
+1
