System V yacc / perl problem

Brandon Allbery allbery at ncoast.UUCP
Tue Feb 23 23:47:28 AEST 1988


As quoted from <3328 at cbmvax.UUCP> by grr at cbmvax.UUCP (George Robbins):
+---------------
| In article <1675 at van-bc.UUCP> sl at van-bc.UUCP (Stuart Lynne) writes:
| > I can successfully generate perl on my ancient Callan (a Unisoft 5.0 system, 
| > basically System V release level 0 with some BSD ism's), but not on my modern,
| > uptodate, state of the art System V release 3 for the 386 at work!!!
| > 
| > The problem is yacc. I get the following results when make try's to generate
| > perl.c from perl.y:
| ...
| > 	 fatal error: out of state space, line 595
| 
| Well, I have the same problem on my creaky old Zilog system.  I don't know
| if yacc is actually runninng out of memory, or if it's just that in a binary
| release, you get a version of yacc compiled with the parameters set to fit
| the "worst case" i.e. PDP-11 / Zilog non-segmented / 8088 small-model
| memory constraints...
+---------------

Plexus P/35 Sys3.31 has the same problem.  So I yacc'ed it on my 3B1.  ;-)
It does seem to be a compiled-in constant.  Yacc in particular seems to be
rather bad in that respect:  not only are most of the table sizes fixed at
compile time, so are the temporary and output file names (yacc.acts, yacc.tmp;
y.tab.[ch]).  I don't see any reason for this, offhand; I've written a parser
generator (nothing as complex as yacc, but it works) which does all that
dynamically.

Maybe it's time to either (a) redesign yacc or (b) drop it in favor of bison?
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
KABOOM!!! Worf: "I think I'm sick." LaForge: "I'm sure half the ship knows it."



More information about the Comp.sources.bugs mailing list