Path: utzoo!attcan!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.lang.c
Subject: Re: scope of malloc
Message-ID: <3739@skye.ed.ac.uk>
Date: 12 Nov 90 16:46:32 GMT
References: <1990Nov07.134942.7355@virtech.uucp> <1990Nov7.234315.15508@athena.mit.edu> <3729@skye.ed.ac.uk> <14413@smoke.brl.mil>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 26

In article <14413@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:

>>You have the choice of rejecting machines or compilers with such serious
>>deficiencies as making alloca() impossible.

>What nonsense.  Being unlike a VAX is hardly a "serious deficiency".

As you know, there are plenty of machines that are quite unlike vaxes
that implement alloca().  I think you would even agree that there are
very few machines on which it is impossible.  So I think your comment
is pointless.

To return to the technical point, it is certainly true that it's hard
to implement alloca() efficiently *as a normal function* on several
processors.  An increasing number of compilers recognise alloca() as a
special case (typically #defining it as __builtin_alloca).  Sun's C
compiler and gcc are examples.  Are there *any* widely-used processors
that can't implement alloca() reasonably efficiently even with
compiler support?

-- Richard

-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin