A bug in LEX?

QNX Newsgroups (Archives) qdn.public.qnx4.devtools
1

Has anyone noticed that there seems to be a bug in LEX?

I’m running QNX V 4.25 and Photon 1.14

According to LEX, it’s version 2.3

I give it a nice simple LEX program:
----------- in the file: eol.l -------------
%%
[ \t]+$ ;

Run over this with lex:
lex -vc eol.l

Throw it to the C compiler:
wcc386 lex.yy.c

The C compiler gripes about:
eol.l(94):Warning! W106:Constant out of range - truncated

If we open up the lex.yy.c file and have a look, we find:
…
static const struct yy_trans_info yy_transition[32] =
{
0, 299736, 0,
…

There is just no way this will ever work. Anybody got any ideas?

Thanks

Steve Shumway
sshumway@facts-inc.com

2

Previously, Steve Shumway wrote in qdn.public.qnx4.devtools:

Has anyone noticed that there seems to be a bug in LEX?

I’m running QNX V 4.25 and Photon 1.14

According to LEX, it’s version 2.3

I give it a nice simple LEX program:
----------- in the file: eol.l -------------
%%
[ \t]+$ ;

Run over this with lex:
lex -vc eol.l

Throw it to the C compiler:
wcc386 lex.yy.c

The C compiler gripes about:
eol.l(94):Warning! W106:Constant out of range - truncated

If we open up the lex.yy.c file and have a look, we find:
…
static const struct yy_trans_info yy_transition[32] =
{
0, 299736, 0,
…

There is just no way this will ever work. Anybody got any ideas?

Thanks

Steve Shumway
sshumway@facts-inc.com

You could try using flex. It’s an easy port.

Cheers,
Andrew

3

Previously, Steve Shumway wrote in qdn.public.qnx4.devtools:

I tried using flex. First thing I thought of actually. The Makefile uses
flex to build flex (of all the crazy things to do). I figured I must be
doing something wrong (using the wrong install script or something). Bottom
line is, the Makefile fails.

That’s funny. Can you change the makefile to use lex to build flex,
then re-build flex with the flex that lex built?

Cheers,
Andrew

4

I tried using flex. First thing I thought of actually. The Makefile uses
flex to build flex (of all the crazy things to do). I figured I must be
doing something wrong (using the wrong install script or something). Bottom
line is, the Makefile fails.

Steve Shumway
sshumway@facts-inc.com

Andrew Thomas <Andrew@cogent.ca> wrote in message
news:Voyager.010326153944.25399367A@andrewhome.cogent.ca…

Previously, Steve Shumway wrote in qdn.public.qnx4.devtools:
Has anyone noticed that there seems to be a bug in LEX?

I’m running QNX V 4.25 and Photon 1.14

According to LEX, it’s version 2.3

I give it a nice simple LEX program:
----------- in the file: eol.l -------------
%%
[ \t]+$ ;

Run over this with lex:
lex -vc eol.l

Throw it to the C compiler:
wcc386 lex.yy.c

The C compiler gripes about:
eol.l(94):Warning! W106:Constant out of range - truncated

If we open up the lex.yy.c file and have a look, we find:
…
static const struct yy_trans_info yy_transition[32] =
{
0, 299736, 0,
…

There is just no way this will ever work. Anybody got any ideas?

Thanks

Steve Shumway
sshumway@facts-inc.com

You could try using flex. It’s an easy port.

Cheers,
Andrew

5

Yes. I tried that. Then I run into the problem that LEX doesn’t work.

I feel like I’m in some kind of Three Stooges sketch.

Steve Shumway
sshumway@facts-inc.com

Andrew Thomas <Andrew@cogent.ca> wrote in message
news:Voyager.010326155800.25399367B@andrewhome.cogent.ca…

Previously, Steve Shumway wrote in qdn.public.qnx4.devtools:
I tried using flex. First thing I thought of actually. The Makefile uses
flex to build flex (of all the crazy things to do). I figured I must be
doing something wrong (using the wrong install script or something).
Bottom
line is, the Makefile fails.

That’s funny. Can you change the makefile to use lex to build flex,
then re-build flex with the flex that lex built?

Cheers,
Andrew

6

Theory:

Since lex produces C source code, perhaps you can run it on a different
OS and save the lex output of that system and then compile that on your
target system?

Steve Shumway wrote:

Yes. I tried that. Then I run into the problem that LEX doesn’t work.

I feel like I’m in some kind of Three Stooges sketch.

Steve Shumway
sshumway@facts-inc.com

Andrew Thomas <> Andrew@cogent.ca> > wrote in message
news:> Voyager.010326155800.25399367B@andrewhome.cogent.ca> …

Previously, Steve Shumway wrote in qdn.public.qnx4.devtools:

I tried using flex. First thing I thought of actually. The Makefile uses
flex to build flex (of all the crazy things to do). I figured I must be
doing something wrong (using the wrong install script or something).

Bottom

line is, the Makefile fails.

That’s funny. Can you change the makefile to use lex to build flex,
then re-build flex with the flex that lex built?

Cheers,
Andrew

7

Thanks to all with their good advice. They are greatly appreciated.

The solution I finally came up with was to get a version of FLEX which
properly does it’s setup shtuff. and doesn’t employ flex to do the build.

The trouble version of FLEX for me was 2.5.4a. I’m still not sure why the
install make file uses flex to build some of the contribution “.C” files. I
wonder if I have some kind of beta test version here, or some other kind of
strange not quite ready for prime time shtuff. Who knows.

The version of FLEX I found that worked for me is: 2.5.2

The version of LEX that comes with QNX is still a looser (I mean this in the
nicest possible way), but there’s not much I can do about that.

Thanks again, and best regards

Steve Shumway
sshumway@facts-inc.com

Steve Shumway <sshumway@facts-inc.com> wrote in message
news:99furd$8o8$1@inn.qnx.com…

Has anyone noticed that there seems to be a bug in LEX?

I’m running QNX V 4.25 and Photon 1.14

According to LEX, it’s version 2.3

I give it a nice simple LEX program:
----------- in the file: eol.l -------------
%%
[ \t]+$ ;

Run over this with lex:
lex -vc eol.l

Throw it to the C compiler:
wcc386 lex.yy.c

The C compiler gripes about:
eol.l(94):Warning! W106:Constant out of range - truncated

If we open up the lex.yy.c file and have a look, we find:
…
static const struct yy_trans_info yy_transition[32] =
{
0, 299736, 0,
…

There is just no way this will ever work. Anybody got any ideas?

Thanks

Steve Shumway
sshumway@facts-inc.com

\

8

i’ve seen that exact bug with lex, and we worked around it by using the command
line options to change the table sizes. Not sure what that affects, but the
warnings went away, and the app that uses it appears to still work (not mine,
and I don’t know lex at all - we just did it as part of an OS/Compiler
upgrade). the yy.lex.c file is quite different, but I assume it’s equivalent.

good to hear of FLEX - we may use that instead in future.

cheers
Lance

Steve Shumway wrote:

Thanks to all with their good advice. They are greatly appreciated.

The solution I finally came up with was to get a version of FLEX which
properly does it’s setup shtuff. and doesn’t employ flex to do the build.

The trouble version of FLEX for me was 2.5.4a. I’m still not sure why the
install make file uses flex to build some of the contribution “.C” files. I
wonder if I have some kind of beta test version here, or some other kind of
strange not quite ready for prime time shtuff. Who knows.

The version of FLEX I found that worked for me is: 2.5.2

The version of LEX that comes with QNX is still a looser (I mean this in the
nicest possible way), but there’s not much I can do about that.

Thanks again, and best regards

Steve Shumway
sshumway@facts-inc.com

Steve Shumway <> sshumway@facts-inc.com> > wrote in message
news:99furd$8o8$> 1@inn.qnx.com> …
Has anyone noticed that there seems to be a bug in LEX?

I’m running QNX V 4.25 and Photon 1.14

According to LEX, it’s version 2.3

I give it a nice simple LEX program:
----------- in the file: eol.l -------------
%%
[ \t]+$ ;

Run over this with lex:
lex -vc eol.l

Throw it to the C compiler:
wcc386 lex.yy.c

The C compiler gripes about:
eol.l(94):Warning! W106:Constant out of range - truncated

If we open up the lex.yy.c file and have a look, we find:
…
static const struct yy_trans_info yy_transition[32] =
{
0, 299736, 0,
…

There is just no way this will ever work. Anybody got any ideas?

Thanks

Steve Shumway
sshumway@facts-inc.com

\