Path: utzoo!utgpu!attcan!uunet!peregrine!elroy!ames!oliveb!sun!thetone!swilson
From: swilson%thetone@Sun.COM (Scott Wilson)
Newsgroups: comp.lang.c
Subject: Re: Are yacc parsers portable ?
Keywords: yacc, bison, parsers
Message-ID: <62170@sun.uucp>
Date: 30 Jul 88 17:36:27 GMT
References: <3950010@eecs.nwu.edu>
Sender: news@sun.uucp
Reply-To: swilson@sun.UUCP (Scott Wilson)
Organization: Sun Microsystems, Mountain View
Lines: 28


> 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
space on the stack that is automatically reclaimed when the function
that calls it exits.  Alloca is found on BSD derived systems and
I am told on other UNIX's.  It, however, is less than universally
available (the manual page states:  "alloca() is both machine- and
compiler-dependent; its use is discouraged").  I had a rather protected
mail war with several people associated with Bison and/or FSF regarding
this.  My opinion was that FSF would be doing computer users a greater
service by writing more portable code when possible.  The gist of the
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.

Writing portable code is not easy.  I would venture to suggest that
unportable code is much more often the result of laziness than lack
of efficiency of portable means.  Even if efficiency is of paramount
importance it is still possible to structure the code for easy porting
in the future.  As an example, in a recent piece of code I wrote I had
#ifdef vax, #ifdef sun, etc, with efficiency-minded machine-dependent
code and then for other machines I had machine-independent code.
Sure it makes the code look uglier, but it also meant the code ran
without change (albeit at less than greatest efficiency) on a Macintosh.

Scott Wilson