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:

Reply via email to