Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!cs326ad
From: cs326ad@ux1.cso.uiuc.edu
Newsgroups: comp.lang.c++
Subject: zortech problem with lex
Message-ID: <6300008@ux1.cso.uiuc.edu>
Date: 24 Feb 90 01:30:29 GMT
Lines: 52
Nf-ID: #N:ux1.cso.uiuc.edu:6300008:000:2299
Nf-From: ux1.cso.uiuc.edu!cs326ad    Feb 23 13:33:00 1990


Here's an interesting question that I pose to people who are familiar
with lex and/or flex.

I am working on a compiler project, and am attempting to do the work at
home instead of on the net.  The work is being done using Zortech's C++, but
I am having a small problem as follows:

In (f)lex definitions, we define whitespace as

ws	[ \t\n]

That is, ws is any one of _blank_, tab, or newline.  If lex runs across this
in the input file, then it takes an appropriate action (in my case, none.)
Now, when porting this code to C++ zortech style, the lex.yy.c program compiles
fine (with a few minor changes.)  However, the executable does NOT recognize
the \n the same as the executable on the net.  i.e.:

If we input:   1234     to the lex executable on the net, I get the output

INT	1234

However, on the zortech implementation, for the same input, I get

INT	1

Doing a little debugging on the zortech code, I came to realize that the
eoln was ended with a   \r\n   for carriage return newline.  Fine.  But
for some reason the zortech implementation does not catch the newline at
the end of the line, like it does on the net.

In addition, I compiled the lex code with Microsoft 5.01, and the program
worked fine.  Same code, different compiler.  There just seems to be an odd
quirk with the zortech implementation of eoln (at least in this case) since
all the lex code does is scan for certain tokens appearing in the input, and
when it matches a token, it performs a given action.

So, the bottom line question is why, with the same code from the same lex
file, I get two different executables from two different compilers.

I hope that this explaination is clear enough.  It is kind of a tough problem
to explain.  Any helpful insight would be appreciated.



===========================================================================
=                                                                         =
=    Mark Allender                               University of Illinois   =
=    cs326ad@ux1.cso.uiuc.edu                    Urbana, Illinois         =
=    ma20449@uxa.cso.uiuc.edu                                             =
=                                                                         =
===========================================================================