Re: lex-flex incompatibility

[Hans-Bernhard Broeker]

On Fri, 11 Jul 2003, Muthumeena M wrote:

> The application has no problem in solaris whereas when i compile the same
> in linux, it is getting stuck at the compilation of the file generated by
> lexer i.e the lex.yy.c file

"Getting stuck" meaning what, exactly?

You're muddying the waters a little by mixing the step from Solaris to
Linux with that from "real" lex to flex.  I think you should try with
flex on Solaris, first, so you can separate out what is caused by the
system difference itself, and what by remaining incompatibilities between
lex and flex.

> The lex output (lex.yy.c) are also quite different in solaris and linux.

There is no such thing as a lex output file on Linux --- because you don't
have genuine lex, there, only flex.  If you have a /usr/bin/lex on a Linux
box, at all, it'll be a script that just does

        exec flex -l "$@"

> The compilation errors are
> 1. In function `unsigned char input()':
> `yysptr' undeclared (first use this  function). it goes on to many other
> undeclared errors.

While not 100% certain, I would say that's a portability bug in your
original lex source.  It's making assumptions about lex internals that
aren't backed up by any standard.  This appears to be fairly common in
historical programs, from my limited experience with cscope.

> So i have manually declared in case of linux.

Declaring them will help quite exactly nothing.  Your lex code assumes
that the lex-generated C code will be *doing* somtthing with those
variables.

> I do not know the reason why this incompatibility is there.

Because the original author didn't bother with portability, that's why.

> 2. After the manual declaration of variables now it is giving
> "previous declaration of int yywrap() with C++ linkage
> conflicts with new declaration with C Linkage"
> and many like this.

What is C++ doing in this game?  Are you compiling lex-generated C as C++,
or what?

> Should the .l file be re-written?

Not so much re-written as thoroughly gone over and fixed.

In the case I work on, I had to eventually get rid of the input() function
override completely, both for performance and for portability reasons.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.