On Sat, Feb 18, 2017 at 10:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > While experimenting with enabling -Werror in the buildfarm, I got > annoyed about the fact that we have to apply -Wno-error while > building some of the flex scanners, because with flex versions > before 2.5.36 you get > > scan.c: In function 'yy_try_NUL_trans': > scan.c:10317: warning: unused variable 'yyg' > psqlscan.c: In function 'yy_try_NUL_trans': > psqlscan.c:4524: warning: unused variable 'yyg' > psqlscanslash.c: In function 'yy_try_NUL_trans': > psqlscanslash.c:1886: warning: unused variable 'yyg' > > I spent some time researching whether there's a way to get rid of that. > It appears that the contents of the yy_try_NUL_trans() function are > fixed depending on the flex options you select, and we don't really want > to change our option choices. So getting these older flex versions to > emit non-broken code seems out of reach. However, there's exactly one > instance of the problematic code, and it's even helpfully labeled: > > { > register int yy_is_jam; > struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* This var may be > unused depending upon options. */ > > register int yy_c = 256; > register yyconst struct yy_trans_info *yy_trans_info; > > yy_trans_info = &yy_current_state[(unsigned int) yy_c]; > yy_current_state += yy_trans_info->yy_nxt; > yy_is_jam = (yy_trans_info->yy_verify != yy_c); > > return yy_is_jam ? 0 : yy_current_state; > } > > It seems like it would be quite simple and reliable to apply a patch > that inserts "(void) yyg;" into this function. (Which, indeed, is > essentially how flex 2.5.36 and later fixed it.) > > I think we could mechanize this as a small perl script that gets invoked > immediately after running flex proper. That way, the fix would already > be applied in "scan.c" and friends in any shipped tarball, and we'd not > be creating any more build-time perl dependency than we already have. > > Obviously, this is pretty ugly. But having to carry -Wno-error on the > scanners for the foreseeable future is no pleasing prospect either. > > Thoughts?
Sounds fine as a master-only fix, but I would vote against back-patching. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers