Path: utzoo!attcan!uunet!husc6!think!ames!vsi1!daver!mfgfoc!exodus
From: exodus@mfgfoc.UUCP (Greg Onufer)
Newsgroups: comp.lang.c
Subject: Re: alloca wars
Message-ID: <395@mfgfoc.UUCP>
Date: 8 Aug 88 13:58:42 GMT
References: <63153@sun.uucp>
Organization: FOCUS Semiconductor Sys., Sunnyvale, CA
Lines: 33

From article <63153@sun.uucp>, by swilson%thetone@Sun.COM (Scott Wilson):
> In article <394@mfgfoc.UUCP> exodus@mfgfoc.UUCP I write:
>>On a M68k with a decent OS, alloca is not more than a few lines of assembly
>>code, correct?  (Judging by the size of the GNU assembly alloca)...
>>If one needs alloca and it is not available, why not write a quick alloca?
> ...
> Again let me say that this whole discussion started with regard to
> portability.  Your solution is to add machine dependent code to a
> program to make it work.  So how does that help future portability?
> It doesn't of course.

Repeat this ten times:
Good C programmers should always know the output of their compiler!!!

And I tried to emphasize the GNU code....  It does it--- portable too.
And if you look at the GNU code (and I think _everybody_ should have copies
of some of the important C files in both Emacs and Gnu C), there _IS_
a portable implementation that works on machines which could not 
reasonably be asked to support proper alloca functionality.  It does
require one to call alloca with a argument of zero to clear free up the
allocated memory (making it no better than malloc, essentially).
This is an example where one could learn from someone else's code.
I'd say GnuEmacs and Gnu C are very excellent sources of education on
portable program writing.

> Scott Wilson		arpa: swilson@sun.com


-- 
Greg Onufer   		GEnie: G.ONUFER		University of the Pacific
UUCP:						-= Focus Semiconductor =-
exodus@mfgfoc ...!sun!daver!mfgfoc!exodus  (and postmaster/exodus@uop.edu)
AT&T: 415-965-0604	USMAIL: #901 1929 Crisanto Ave, Mtn View, CA 94040