Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"yywrap" macro redefined when %option noyywrap given #155

Closed
nvinson opened this issue Jan 8, 2017 · 6 comments
Closed

"yywrap" macro redefined when %option noyywrap given #155

nvinson opened this issue Jan 8, 2017 · 6 comments

Comments

@nvinson
Copy link

nvinson commented Jan 8, 2017

Description:
This is based on the error seen with Gentoo bug #604732 (https://bugs.gentoo.org/show_bug.cgi?id=604732).

Specifying the noyywrap option causes GCC to emit a warning about yywrap being redefined. This does not happen if %option noyywrap is replaced with a correct yywrap() function definition.

Steps to reproduce:
Create input file:

%option noyywrap
%%
%%

Run flex input.l
gcc -c input.c
observe warning

The expected result is for no warning to be emitted.

@westes
Copy link
Owner

westes commented Jan 10, 2017

@DemiMarie do you have any thoughts on this? I assume this is the same issue as in #152 and #154.

@jannick0
Copy link
Contributor

I think in the proposed case the macro yywrap is defined twice in input.c:

#define yywrap yywrap // since flex 2.6.2 or 2.6.3, NB: to be guarded if yywrap defined below, i.e. %option noyywrap

and further down

#define yywrap() (/*CONSTCOND*/1)

@jannick0
Copy link
Contributor

Why not simpy defining yywrap as a function instead of a macro (see main.c:1588++)?

Separately, it appears that in flex.skl:58 (see snip below) m4's ifelse statement always drops into the false branch, as by code interpretation this should no be the case if the prefix is not redefined.

%not-for-header
%if-c-only
%if-not-reentrant
m4_ifelse(M4_YY_PREFIX,yy,,
#define yy_create_buffer M4_YY_PREFIX[[_create_buffer]]
[snip]
)

@jannick0
Copy link
Contributor

A suggested patch to define yywrap as function instead of a macro I just tested for simple cases:

--- main.c	Thu Dec 29 21:03:14 2016
+++ main.c	Fri Jan 13 13:28:59 2017
@@ -1586,9 +1588,9 @@
 	if (!do_yywrap) {
 		if (!C_plus_plus) {
 			 if (reentrant)
-				outn ("\n#define yywrap(yyscanner) (/*CONSTCOND*/1)");
+				outn ("\nint yywrap(yyscanner) { return /*CONSTCOND*/1; }");
 			 else
-				outn ("\n#define yywrap() (/*CONSTCOND*/1)");
+				outn ("\nint yywrap(void) { return /*CONSTCOND*/1; }");
 		}
 		outn ("#define YY_SKIP_YYWRAP");
 	}

@westes
Copy link
Owner

westes commented Jan 23, 2017

Looks like the same issue as #162; please confirm that you see this fixed for you on master now.

@nvinson
Copy link
Author

nvinson commented Jan 25, 2017

Fixed on master. Thanks.

@westes westes closed this as completed Jan 25, 2017
fishilico added a commit to fishilico/selinux-notforked that referenced this issue Feb 5, 2017
…-generated code

This is a bug in flex 2.6.3:
westes/flex#155

lex.yy.c:397:0: error: "yywrap" redefined [-Werror]
lex.yy.c:73:0: note: this is the location of the previous definition
fishilico added a commit to fishilico/selinux-notforked that referenced this issue Feb 5, 2017
…-generated code

This is a bug in flex 2.6.3:
westes/flex#155

lex.yy.c:397:0: error: "yywrap" redefined [-Werror]
lex.yy.c:73:0: note: this is the location of the previous definition
fishilico added a commit to fishilico/selinux-notforked that referenced this issue Feb 6, 2017
…-generated code

This is a bug in flex 2.6.3:
westes/flex#155

lex.yy.c:397:0: error: "yywrap" redefined [-Werror]
lex.yy.c:73:0: note: this is the location of the previous definition
fishilico added a commit to fishilico/selinux-notforked that referenced this issue Feb 18, 2017
…-generated code

This is a bug in flex 2.6.3:
westes/flex#155

lex.yy.c:397:0: error: "yywrap" redefined [-Werror]
lex.yy.c:73:0: note: this is the location of the previous definition
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants