Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!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: <3754@skye.ed.ac.uk>
Date: 14 Nov 90 14:08:37 GMT
References: <3729@skye.ed.ac.uk> <14413@smoke.brl.mil> <3739@skye.ed.ac.uk> <14448@smoke.brl.mil>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 34

In article <14448@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>It can't be implemented correctly (except by the compiler turning it into
>malloc()/free() calls that you could have coded yourself) on any system
>that doesn't provide separate frame and stack pointers.  Just consider
>the effects of an interrupt.

I assume you mean a system that accesses locals by offsets from the stack 
pointer, implements alloca() by using space beyond the stack pointer,
and receives interrupts on the same stack.  This indeed cannot work.

However, the frame pointer doesn't have to be a dedicated register.
The compiler can just allocate a register for local references in
functions that call alloca().  (I assume that compilers like gcc which
have an option to not use a frame pointer have the same problem, and
disable this option in functions that call alloca()).

And of course if the compiler can turn it into malloc()/free() calls
*and ensure the free() gets done when a longjmp() occurs (which the
user can't)*, then this would be a reasonable implementation.

>It also cannot be reasonably implemented on
>a system that uses linked stack frames, such as on the IBM System/370.

This might be a problem, but as Richard O'Keefe has pointed out, they
would have to solve it to implement various other languages.  A
solution in C (which only has local and global variables, and wouldn't
therefore have to follow the frame chain) might be to implement
alloca() by inserting a frame in the chain.

-- 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