Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!inmos!conor@lion.inmos.co.uk
From: conor@lion.inmos.co.uk (Conor O'Neill)
Newsgroups: comp.lang.c
Subject: Re: scope of malloc
Message-ID: <12559@ganymede.inmos.co.uk>
Date: 13 Nov 90 13:37:57 GMT
References: <1990Nov07.134942.7355@virtech.uucp> <1990Nov7.234315.15508@athena.mit.edu> <3729@skye.ed.ac.uk> <14413@smoke.brl.mil> <2182@kraftbus.opal.cs.tu-berlin.de>
Sender: news@inmos.co.uk
Reply-To: conor@inmos.co.uk (Conor O'Neill)
Organization: INMOS Limited, Bristol, UK.
Lines: 23

In article <2182@kraftbus.opal.cs.tu-berlin.de> net@tubopal.UUCP (Oliver Laumann) writes:
>I'm not aware of any plausible reason why vendors should omit something
>as useful and simple to implement as alloca() from their UNIX systems.
>
>Yes, I know that alloca() may not work with certain existing C
>compilers, but why, for instance, can't vendors with such types of
>compilers add an option to support alloca() (like, e.g. Greenhills have
>done with their C compiler) or implement alloca() as a built-in function
>(like the SunOS cc does)?

On some machines you require a different calling sequence if you want
to be able to implement alloca than would be required if you do not
need to implement alloca. (This is due to the requirement for
both a stack pointer and a frame pointer).
The different calling sequences may have different costs.

Some customers would prefer a faster C system _without_ alloca than
a slower C system _with_ alloca.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".