On Sat, Feb 18, 2017 at 10:40 PM, Tom Lane <tgl@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