Alloca, FSF software assumptions (was: Re: Are yacc parsers portable ?)

[Michael]

In article <62170 at sun.uucp> swilson at sun.UUCP (Scott Wilson) writes:
>
>> Is Bison any better ...
>
>My main complaint with Bison was that both the source for Bison (last I
>looked) and the parser it produces rely on alloca - a method for allocating
>
>available (the manual page states:  "alloca() is both machine- and
>compiler-dependent; its use is discouraged").  I had a rather protected
>
>replies I recieved was that it is "impossible" to write code that is worth
>anything without taking advantage of nifty features like alloca.  I
>completely disagree.

Actually, alloca() isn't that big of a problem. Annoyance, yes, but you
can get a PD version of alloca that is nearly identical and 98%+ portable,
and I've seen completely compatible subroutines for ibm's, 68K's, pdp's, etc.

What really gets me in all the FSF software I've looked at is...

"Memory is cheap, and always will be. If they don't have at least 8 megs
of virtual space with reasonable performace times, they don't count".

The C compiler takes 500K+ 
		     ====
The C preprocessor takes up rediculous amounts of memory (200K+) for something
the standard preprocessor does in 50K. Why?

They want to keep everything in memory.
They want to keep everything in memory.
And, they want to keep everything in memory.

(As in: Well, we need 2 more bytes of memory, so call realloc(). Realloc()
cant get it from free space, so call sbrk() for the full amount, then
copy it there. Repeat as needed.).

Of course, it does have some benefits. You can preprocess the recursion
winner of the C contest in finite time.
: --- 
: Michael Gersten			 uunet.uu.net!denwa!stb!michael
:				sdcsvax!crash!gryphon!denwa!stb!michael
: What would have happened if we had lost World War 2. Well, the west coast
: would be owned by Japan, we would all be driving foreign cars, hmm...