Re: Converting a lex scanner to flex, help needed (Aharon Robbins)
Thu, 30 Dec 2021 08:10:27 -0000 (UTC)

          From comp.compilers

Related articles
Converting a lex scanner to flex, help needed (2021-12-29)
Re: Converting a lex scanner to flex, help needed (2021-12-30)
| List of all articles for this month |

From: (Aharon Robbins)
Newsgroups: comp.compilers
Date: Thu, 30 Dec 2021 08:10:27 -0000 (UTC)
Organization: NNTP Server
References: 21-12-019
Injection-Info:; posting-host=""; logging-data="48385"; mail-complaints-to=""
Keywords: lex, question, comment
Posted-Date: 30 Dec 2021 13:23:43 EST

In article 21-12-019,
Aharon Robbins <> 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
>yytext, which
>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]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.