Description of problem: A certain combination of options causes flex to generate parsers that redefine yywrap. This problem does not happen with vanilla flex 2.5.33. A perusal of the changelog suggests that it may have been introduced in 2.5.33-5. Version-Release number of selected component (if applicable): 2.5.33-5 I've removed the remaining boilerplate text and am providing examples of how to reproduce the problem. Extract the attached files: example.fl and ExampleLexer.hh. Run the following: flex -+ -o FlexLexer.example.cc example.fl g++ -c -I. FlexLexer.example.cc Actual output: FlexLexer.example.cc:330:1: warning: "yywrap" redefined FlexLexer.example.cc:23:1: warning: this is the location of the previous definition Expected output: There should be no warnings. The problem is that the patch (flex-2.5.33-yy.patch) creates a definition for yywrap unconditionally. It should not do this if %option noyywrap is defined. Run
Created attachment 156239 [details] tarfile containing example.fl and ExampleLexer.hh
I am seeing this issue too. From the flex code and the patch, it looks like the problem is this. All the symbols being #defined in flex-2.5.33-yy.patch are being modified with specified prefix only in C mode, not in C++ mode. In C mode, with noyywrap, we are okay since the output file later defines Prefix_wrap(n) rather than redifining yywrap. But in C++ mode, this leads to a redefinition of yywrap. Solution would be to surround the lines introduced by this patch with %if-c-only, %endif, (directly for flex.skl and strings of these for skel.c) since they don't seem to be useful for C++ mode anyway. I will attach a suitably modified 2.5.33-yy.patch after I test it.
Created attachment 157163 [details] A modified flex-2.5.33-yy.patch which fixes this issue for me. Diff from the earlier patch is: $ diff flex-2.5.33-yy.patch flex-2.5.33-yy-fix.patch 4c4 < @@ -54,6 +54,32 @@ m4_changequote([[, ]]) --- > @@ -54,6 +54,34 @@ m4_changequote([[, ]]) 9a10 > +%if-c-only 31a33 > +%endif 40c42 < @@ -59,6 +59,32 @@ const char *skel[] = { --- > @@ -59,6 +59,34 @@ const char *skel[] = { 45a48 > + "%if-c-only", 67a71 > + "%endif",
I applied fix and built new package. It should hit the repository in several days. Thanks for patch!
flex-2.5.33-9.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Please could you reintroduce this patch (and try to move it upstream)? This problem still persists with flex in F10.
The patch was dropped because upstream contains the code. And indeed, F-10 version seems to work for me: $ ~/fedora/flex/F-10/flex-2.5.35/flex -+ -o FlexLexer.example.cc example.fl $ g++ -c -I. FlexLexer.example.cc
Created attachment 331314 [details] Simple test file Hm, for the example.fl file it works, but look at the simple file I've attached (plain.l): >flex -o plain.c plain.l >gcc plain.c plain.l:4:1: warning: "plainwrap" redefined plain.c:354:1: warning: this is the location of the previous definition [...the rest of output is not important] Maybe it's because we build a C scanner, not C++?
Your file contains the "%option noyywrap" directive: """If you do not supply your own version of `yywrap()', then you must either use `%option noyywrap' (in which case the scanner behaves as though `yywrap()' returned 1), or you must link with `-lfl' to obtain the default version of the routine, which always returns 1.""" So just either drop the directive, or your own "plainwrap" macro.
You're right of course and I'm very sorry and thank you for clarification. Unfortunately there is one more such a dumb warning, I'm afraid that this time it's not just my fault -- it is filed as bug 484961.