kak@stc-auts.UUCP (Kris Kugel) (04/28/88)
On the suggestion of a fellow netter, I tried recompiling some
lex code using the -f flag (no table compression) to see if I
could speed it up some.
But when I tried to run it, it started dumping core.
I removed the -f flag, and the core dumps stopped. I compared
the two output files from lex, and they seemed to differ only
in data. I then tried tracing both versions, and the one that
didn't work failed to recognize the end of the input, and ran
off the end of the world.
the difference seems to be that the test in the statement
(near *yylastch = yych = input())
if ( yyt == yycrank && !yyfirst )
fails on the -f version at the end of file, (yyt was == yycrank +1)
while the non-f version exits on a break inside the body of the if.
Does anybody know what would cause this problem? is the -f flag
bad news?
Kris A. Kugel
Storage Tek: ...{ uunet!nbires, ncar, ihnp4 }!stcvax!stc-auts!kak
(p.s this happended with ULTRIX and Sun 3.2, both BSD 4.2 variants)tps@chem.ucsd.edu (Tom Stockfisch) (04/29/88)
In article <255@stc-auts.UUCP> kak@stc-auts.UUCP (Kris Kugel) writes: > >On the suggestion of a fellow netter, I tried recompiling some >lex code using the -f flag (no table compression) to see if I >could speed it up some. As I understand it, this is supposed to make lex create the lex.yy.c file faster, at the expense of making the lex.yy.c file bigger. Given that "cc lex.yy.c" takes an order of magnitude longer than "lex lex.l", I don't know why anyone would want to use this flag. Perhaps that's why no one has noticed till now that it doesn't work: >But when I tried to run it, it started dumping core. > Kris A. Kugel -- || Tom Stockfisch, UCSD Chemistry tps@chem.ucsd.edu