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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers