Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!vsi1!altos!megadon!clp
From: bliss@sp64.csrd.uiuc.edu (Brian Bliss)
Newsgroups: comp.unix
Subject: Re: bug in SUN lex++; and whinge about fixed table sizes
Keywords: lex yacc lex++ yacc++ GNU SUN Unix
Message-ID: <2183@megadon.UUCP>
Date: 10 Oct 90 23:31:10 GMT
References: <2158@megadon.UUCP>
Sender: clp@megadon.UUCP
Reply-To: bliss@sp64.csrd.uiuc.edu (Brian Bliss)
Organization: Center for Supercomputing Research and Development
Lines: 23
Approved: clp@megadon.UUCP

Well, I do have access to the source for yacc...

when trying to parser pre-tokenized fortran I ran into problems
with having too many tokens for yacc on the alliant fx/8 to
handle (> 128).  so I go into the source and changed the NTERM
constant appropriately.  now everything compiles correctly,
but it bombs at run-time.  it turns out that I was manually
assigning values to the tokens that were larger than 256,
and yaccpar was bombing.  I couldn't change the token values
(in order to be compatible with someone else's code), so
I up NTERM to 2056.  it still bombs at run-time.  it turns
out that there is a constant, YYFLAG (-1000 by default), such
that NTERM must be less than -YYFLAG.  of course, this was
not documented in the source.  so I change YYFLAG to -2000
(I wasn't using tokens in the range 2000-2056 - in retrospect,
I should have made it -3000).  still bombs.  turns out that
YYFLAG is defined in two places, once for the yacc soruce
(so that it generates the appropriate tables), and again
in yaccpar (the c code that is included with the generated
tables to form the parser).  not only that, but I had to 
redefine the NOMORE constant in the yacc source.

3 days later I got it to work...