Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!ukc!edcastle!aipna!rjc
From: rjc@uk.ac.ed.cstr (Richard Caley)
Newsgroups: comp.lang.c
Subject: Re: scope of malloc
Message-ID: <RJC.90Nov13125034@brodie.uk.ac.ed.cstr>
Date: 13 Nov 90 12:50:34 GMT
References: <3729@skye.ed.ac.uk> <14413@smoke.brl.mil>
	<2182@kraftbus.opal.cs.tu-berlin.de> <14437@smoke.brl.mil>
Sender: news@aipna.ed.ac.uk
Organization: Center for Speech Technology Research
Lines: 30
In-reply-to: gwyn@smoke.brl.mil's message of 12 Nov 90 13:46:14 GMT

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

    It's not simply a compiler issue; many interesting computer achitectures
    are such that alloca() cannot be reasonably implemented, particularly if
    you take into account interrupts (signals).

    In article <2182@kraftbus.opal.cs.tu-berlin.de> net@tubopal.UUCP (Oliver Laumann) writes:
    >You also keep mentioning the argument that alloca() is not needed.  If
    >this is true, then how do you make sure that in the following
    >function, [ simple callback scheme... ]

    I don't write spaghetti code.

My someone got out of bed the wrong side one Monday morning :-)

The code that was shown was not particularly opaque and was certainly
not unusual, it is the kind of thing that anyone putting together
generally useful support routines is going to have to do. 

As you point out, the same thing happens with interrupts.

Also, to tie in another thread, since one can't do line at a time
input without dynamically alocating memory, are we to assume that any
code of mine which is to be included in a larger system beyond my
control may not do line at a time input? Or are we all to live in
programmer heaven where all systems are one man jobs and are not
modified once completed?

--
rjc@uk.ac.ed.cstr