scope of malloc

[Oliver Laumann]

In article <14413 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
> In article <3729 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) 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".

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

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,
which invokes another function that is supplied by user, the memory is
freed in case the user-supplied function doesn't return (i.e. invokes
longjmp())? --

   void wrapper (callback) void (*callback)(); {
       char *p;
       ...
       p = malloc (...);
       /* do something, then call user-supplied function */
       callback ();
       /* do something */
       free (p);
   }

Note that the implementor [implementer?] of the function "wrapper" has
no control over what "callback" does; "callback" is supplied by the
module's user.

Yes, I know that there do exist methods to solve problems like this
without using alloca() (I myself had to invent one for Elk, which
makes heavy use of alloca()), but a what price?

--
    Oliver Laumann, Technical University of Berlin, Germany.
    pyramid!tub!net   net at TUB.BITNET   net at tub.cs.tu-berlin.de