Suppressing that pesky warning with older flex versions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Suppressing that pesky warning with older flex versions
Date: 2017-02-18 17:10:42
Message-ID: 25456.1487437842@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2017-02-18 17:15:40 Re: Parallel bitmap heap scan
Previous Message Jim Nasby 2017-02-18 16:19:34 Re: "SQL sentence"?