Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!tymix!cirrusl!sunstorm!dhesi From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Newsgroups: comp.lang.c Subject: Re: scope of malloc Message-ID: <2698@cirrusl.UUCP> Date: 14 Nov 90 05:58:18 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@cirrusl.UUCP Organization: Cirrus Logic Inc. Lines: 43 In <2182@kraftbus.opal.cs.tu-berlin.de> net@opal.cs.tu-berlin.de (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. I too am not aware of one. The designers of Ada assumed that such functionality would be available in the language, and this is why they didn't worry too much about requiring the equivalent of a free() function in the language. (Well, actually, they did worry about it, but in the reverse manner, arguing that the availability of an unchecked way of freeing allocated memory was dangerous, and it had better be indicated so in bold letters that read something like UNCHECKED_DEALLOCATION. Their preference was for the memory allocated for objects in the heap to be freed automatically when the scope of the objects expired at run-time, i.e., through a mechanism equivalent to alloca().) I think the problem, to quote Chris Torek somewhat out-of-context, is that you're in a circle and it's hard to break out of it. Since alloca() must properly be designed into the compiler, it's hard to find "prior art" in the form of user-written functions. Since programmers can't always assume the availability of alloca(), they find ways around it -- and I suspect some of them, having worked hard to find ways around it, aren't sympathetic to others who don't want to work so hard. I'm sure there are some very-CISC machine architectures in which procedure exit is a single instruction, and adding alloca() would result in less efficient procedure exit code that couldn't use this single instruction. But I don't see why alloca() should be impossible, or even difficult, to implement on any machine. Heck, if you can implement a recursive language on a machine that doesn't have a stack to begin with (e.g. IBM 360 onwards), and not complain about how "impossible" it is to write a PL/1 compiler, you can surely implement alloca() on every machine in the world. There's enough prior art now, though, that perhaps the next team that revises the C standard may be persuaded to add alloca() to it. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi