Related articles |
---|
incantation(s) for using flex-generated code on Windows/Visual C++ themattfella@xxyyyzzzz.com (Matt) (2006-03-15) |
From: | Matt <themattfella@xxyyyzzzz.com> |
Newsgroups: | comp.compilers |
Date: | 15 Mar 2006 22:11:55 -0500 |
Organization: | Compilers Central |
Keywords: | lex, question |
Posted-Date: | 15 Mar 2006 22:11:55 EST |
I am using flex (version 2.5.4) to generate a lex.yy.c under Linux
(Fedora Core 4).
The scanner works when compiled and run under Linux. Then I compile
the linux-generated lex.yy.c on Windows XP SP2 and Visual C++ 2005
Express. The scanner processes its inputs incorrectly when compiled
with Visual C++.
I wonder whether there is some trick to compiling that lex.yy.c with
Visual C++.
VC++ puts out a couple of warnings (namely C4267 and C4244) related to
64-bit migration. I am running on a Pentium 4 machine, so I believe I
can safely ignore those or silence them by turning off the /Wp64 flag.
Am I wrong about that?
I hope these are rest of the important details:
I place:
#define YY_NEVER_INTERACTIVE 1
in flex's input, and I use sed to remove from lex.yy.c a line like:
#include <unistd.h>
I rename the file from lex.yy.c to lex.yy.cc.
I do all of the above for both Linux and Windows builds.
The scanner has only two flex rules:
%%
(.|\n){6} { return 1; }
(.|\n) { extrachar(); }
%%
extrachar() just reports the hex code of the matched character without
returning.
So you can see that the scanner should consume any input file six
characters at a time (returning each time) and (in case the file length
is not divisible by six) report any remaining characters one at a time.
Under Windows/VC++, the scanner calls yywrap() long before it processes
all the input. It behaves as if the input buffer is going empty before
it should. The misbehavior seems to depend on the inputs, though: I
haven't seen the problem when the input characters are all printable.
But it always goes wrong when the input is binary data such as an object
file.
I build the VC++ project as a console application.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.