|Converting a lex scanner to flex, help needed email@example.com (2021-12-29)|
|Re: Converting a lex scanner to flex, help needed firstname.lastname@example.org (2021-12-30)|
|From:||email@example.com (Aharon Robbins)|
|Date:||Thu, 30 Dec 2021 08:10:27 -0000 (UTC)|
|Organization:||Aioe.org NNTP Server|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="48385"; mail-complaints-to="firstname.lastname@example.org"|
|Keywords:||lex, question, comment|
|Posted-Date:||30 Dec 2021 13:23:43 EST|
In article 21-12-019,
Aharon Robbins <email@example.com> wrote:
>I am trying to convert a V7 Unix vintage lex scanner to flex.
>[In flex a . doesn't match a newline. What do you see when you look at
>is the token it matched? The input buffer doesn't tell you anything
>very useful about
>individual matched tokens. -John]
You're right, it looks like yytext is fine. There seems to be
other stuff going on between the grammar and the scanner, with the
grammar poking around inside the input buffer and expecting things to
work the way they did in lex.
I will probably have to dive into the code more deeply, instead of
just mechanically fixing compilation warnings, which is mostly
what I've been doing so far.
As an aside, the original code very cavalierly converted int to pointer
and back, all over. Over 40 years later, it's really hard to have
to mess with code like this.
Interestingly enough, though, when compiled in 32 bit, where int
and pointer are the same size, things seem to actually work!
Aharon (Arnold) Robbins arnold AT skeeve DOT com
[Urrgh. The file handling in flex is quite different from lex. In lex
it's very simple, I think it just read a line at a time into a buffer,
in flex it reads large blocks and uses pointers to keep track of where
it is, with some cleverness if a token spans a block boundary. In lex
yytext is an array,in flex it's normally a pointer. -John]
Return to the
Search the comp.compilers archives again.