Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP
Path: utzoo!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!jsq
From: jsq@ut-sally.UUCP (John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: Storage allocators
Message-ID: <2592@ut-sally.UUCP>
Date: Mon, 5-Aug-85 13:46:28 EDT
Article-I.D.: ut-sally.2592
Posted: Mon Aug  5 13:46:28 1985
Date-Received: Tue, 6-Aug-85 17:13:00 EDT
References: <2561@ut-sally.UUCP> <2579@ut-sally.UUCP> <2590@ut-sally.UUCP>
Reply-To: std-unix@ut-sally.UUCP
Organization: U. Texas CS Dept., Austin, Texas
Lines: 45
Approved: jsq@ut-sally.UUCP

----------------------------------------------------------------------

From: seismo!BBN-LABS-B.ARPA!dan
To: ut-sally!BBN-LABS-B.ARPA!std-unix
Subject: Re: Storage allocators
Date: 05 Aug 85 12:30:18 EDT (Mon)

Much as I like alloca() in theory, I have to agree with Doug Gwyn that it is
not always implementable--at least, if you are starting with the runtime
environment already designed.  Alloca() is a LANGUAGE feature, not a library
feature; it just happens that on many UNIX machines it is possible to add it to
the library and slip it past the compiler as long as you don't try to use it
too hard.  On many systems, if you do

	routine_with_args(arg1, arg2, arg3, ..., alloca(100), argN,...);

the alloca() will screw things up completely because the arguments before and
after it were pushed on the stack--that is, are SP-relative--and alloca() has
munged the SP.  Sufficiently complex expressions can also cause this problem.
Unless alloca() is known to the compiler it usually cannot be implemented
correctly.

However, I don't understand Doug's comment about it encouraging sloppy
programming practice.  Alloca() provides the programmer with the ability to
declare automatic variables whose size is determined at runtime rather than
compile time; thus the size can reflect the size of input data, which is GOOD
programming practice.  If the makers of UNIX had had alloca() when they did
execvp(), they would not have (a) relied on the existence of array[-1], or (b)
assumed that there would not be more than 200 values in the array (as different
versions of that library routine did).  I don't think anyone would argue that
the use of alloca here would have resulted in sloppier code!  The only
alternative, if you want to be a good programmer, is to use malloc(), which is
relatively slow and quite clumsy.  I have never subscribed to the point of view
that not having to explicitly allocate and free each variable is "sloppy
programming practice"; that's what auto vars are, after all.

	Dan Franklin

------------------------------

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
Submissions-To:	ut-sally!std-unix	or std-unix@ut-sally.ARPA
Comments-To: ut-sally!std-unix-request	or std-unix-request@ut-sally.ARPA
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)