Bug 4136 - insufficiency from mismatch of FLEX capability between released tarball and build host
insufficiency from mismatch of FLEX capability between released tarball and b...
Product: unbound
Classification: Unclassified
Component: server
All All
: P5 normal
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2018-07-28 10:55 CEST by OBATA Akio
Modified: 2018-08-06 09:19 CEST (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description OBATA Akio 2018-07-28 10:55:54 CEST
If there is mismatch of FLEX capability between released tarball and build host,
required functions may not be used.

LEX related features will be checked in configure script, currently (1.7.3) yylex_destroy, and recorded in config.h and used in build.

It is OK to build from scratch, but may not good for released tarball users.
LEX files has been handled in release tasks, currently it has yylex_destroy.
But users may not have such flex command, so configure will record as missing yylex_destroy in config.h regardless of existing source codes in released taball having yylex_destroy, and yylex_destroy will not be used even though it is required.
Comment 1 Wouter Wijngaards 2018-07-30 10:08:18 CEST

Could this be the same flaw as fixed in:
        - Fix #4131: for solaris, error YY_CURRENT_BUFFER undeclared.

But this is in the (not yet released) code for 1.7.4, in the code repository.

If so, there is already a fix and the next release fixes it.  If not, please say so, and then I would like to know more about what is going wrong.

Best regards, Wouter
Comment 2 OBATA Akio 2018-07-30 11:48:24 CEST
Your suggested change is that check LEX command capabilites,
and ignore unwanted LEX command then prevent to regen 'util/configlexer.c'.

It is not same issue.

For example, in such case, "ACX_YYLEX_DESTROY" is also failed (or not invoked)
in configure, then "LEX_HAS_YYLEX_DESTROY" will not be defined in 'config.h'.
'util/configlexer.c' in released tarball contains "yylex_destroy()" function,
and will not be overwrite with unwated LEX command.
"yylex_destroy()" is renamed as "ub_c_lex_destroy()" with "util/configyyrename.h".
But "daemon/daemon.c" will not invoke it because LEX_HAS_YYLEX_DESTROY is not defined whereas it exists in the source code.

Maybe, it is better to define no-op "yylex_destroy" in 'util/configlexer.c'
if "LEX_HAS_YYLEX_DESTROY" is not defined, and use "ub_c_lex_destroy()" unconditionally in "daemon/daemon.c".
Comment 3 Wouter Wijngaards 2018-07-30 12:00:34 CEST

Thank you for the report, I have fixed as you said: it defines a dummy destroy function in the configlexer file and calls it unconditionally from the daemon.c file.

The code is in the code repository for it.  Does this fix the issue you have?  (I think so, and in anticipation, I've closed the bugreport, but if not, please say so).

Best regards, Wouter
Comment 4 OBATA Akio 2018-08-03 02:58:13 CEST
No, duplicated yylex_destroy() will be delared for relevant situation.
"no-op" yylex_destroy() should be inserted conditionally in Makefile at generatig util/configlexer.c

Or just ignore such LEX command, same as Solris's situation simplify?
Comment 5 Wouter Wijngaards 2018-08-03 11:51:08 CEST

So I have reverted the previous fix, this should remove the issue that was introduced by it and also the issue faced by someone on the users mailing list.

Now, back to solving the original issue, but without introducing more trouble

Did you say that a solution may be to ignore lex that does not create yylex_destroy?

Best regards, Wouter
Comment 6 OBATA Akio 2018-08-03 13:05:51 CEST
Yes if such solution is acceptable.
Comment 7 Wouter Wijngaards 2018-08-03 13:11:44 CEST

Yes certainly, I made it so it ignores lex without yylex_destroy.  That hopefully works for everyone.  It works for me, here.  Code is in the code repository.

Best regards, Wouter
Comment 8 OBATA Akio 2018-08-04 07:02:59 CEST
daemon.c should be changed to do ub_c_lex_destroy() unconditionally too.
Comment 9 Wouter Wijngaards 2018-08-06 09:19:20 CEST
Hi OBATA Akio,

Thanks for the excellent code change suggestions!  This change also makes the code nicer, I've added it.

Best regards, Wouter