Path: utzoo!attcan!uunet!murtoa.cs.mu.oz.au!munnari.oz.au!basser!steve
From: steve@basser.oz (Stephen Russell)
Newsgroups: comp.os.minix
Subject: Re: FLEX : good news for the ST
Message-ID: <2306@basser.oz>
Date: 30 Jun 89 17:09:30 GMT
References: <18666@louie.udel.EDU> <1568@cod.NOSC.MIL>
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 29

In article <1568@cod.NOSC.MIL> hall@cod.NOSC.MIL (Robert R. Hall) writes:
>
>
>I was able to get flex to compile and link using the Minix
>C compiler but I can't get it to run, it runs out of stack
>space.
>
>MINIX> size flex
>  text	  data	   bss	 stack	memory
> 35344	 22116	 30558	 12862	100880	flex
>
>MINIX> flex
>flex: fatal internal error memory allocation failed in allocate_array()

As I mentioned in an earlier posting, some of the flex data can be
shrunk considerably. For example, much of the bss space is in the input
buffers defined in scan.c (actually, they're defined in the skeleton
scanner). These could be much smaller, although this limits the maximum
size of a token.  There is also a state stack which chews up some
space, and could be shrunk.  In fact, I believe only two files are
responsible for most of the bss.

As well, there are various initial sizes for dynamically allocated
tables defined in flexdef.h. Some of these can be shrunk, particularly
as flex resizes tables as needed. Even running flex on its own scanner
definition (which is quite complex) doesn't need these tables to be as
large as they are.

Don't give up yet. Changing a few #define's may make it squeeze in.