Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: alloca
Message-ID: <8293@smoke.ARPA>
Date: 2 Aug 88 05:36:29 GMT
References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <62363@sun.uucp> david@sun.uucp (David DiGiacomo) writes:
>The FSF people aren't evil (?), they just disagree with the author of that
>man page blurb about the usefulness and implementation difficulty of
>alloca.  By distributing excellent software which makes good use of
>alloca, they are ensuring that all self-respecting C compiler/library
>vendors will provide an efficient implementation of it.

The C vendors aren't evil (?) either; requiring support for alloca()
does impose an undue burden on implementations on some architectures.

>They even help out the alloca-deprived by providing Doug Gwyn's malloc
>based alloca.

I provided that with the intention of helping people who had to import
existing code that relied on alloca(), not to encourage its use in new
code.  In fact my emulation of alloca() can fail to reclaim free memory
under some unusal circumstances.

Please don't use alloca() in new code.  Thanks.