-
Notifications
You must be signed in to change notification settings - Fork 115
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
Fixing compile-time warnings #8
Comments
Thank you for reporting issues here. I found yyuserAction name in \bison\data\glr.c file only. It's skeleton file to produce actual generator source code. I didn't modify it during migration to windows system. There is no newer version of GNU bison tool available. So if you want we can fix it by ourself, just give me a patch that fixes the code. For the second warning I can upgrade win_flex from 2.6.3 to 2.6.4 and give you to test. If it fixes warnings I'll publish a new release. Regards, |
PR #9 created, fixing the first warning. |
Fixed 'possible data loss' warning inside Flex yyuserAction() - part of issue #8
@lexxmark , thanks merging the fix! The other problem appears to be already fixed in Flex 2.6.4:
Would be nice to update winflexbison to 2.6.4 soon. WDYT? |
I'm working on it. Thank you |
Please try upgrated win_flex.exe executable: |
I just completed an extensive check. Works well now. Thanks a lot! |
You are welcome! |
We have updated to the latest version of winflexbison after switching to C++17. Good news is that there are no more
register
variables in the generated code.However, there are two new warnings in the generated code introduced by winflexbison version 2.6.3, which were not the case with version 2.5.37:
(possible information loss) In
yyuserAction()
argumentsize_t yyrhslen
is used to to compute an argument toyyfill()
, which isint
.(macro redefined) Macro
yylex
is defined in lexer and then re-defined in parser (yes, we use an intermediate layer, hencein the scanner (no such declaration here with v.2.5.37), and
in the parser.
The second problem might be related to westes/flex#162, which is fixed there.
The text was updated successfully, but these errors were encountered: