Why didn't ANSI/ISO make alloca() standard?

[Nitin Bhardwaj]

Hi all,

I want to know what is wrong with alloca() ?

Is it hard to implement in a platform-independent way?
OR there is no need for it?

AFAIK alloca() /*(used to)*/ allocate memory at run-time from the
function stack, so that the programmer need not call free() to
de-allocate it.Since it automatically got freed when the function
returns, Right?

So what is wrong with implementing such a function..why doesn't the
Standard provide this function?

Thanks.

 

[Richard Bos]

Is it hard to implement in a platform-independent way?
OR there is no need for it?

Both. RTFAQ: <http://www.eskimo.com/~scs/C-faq/q7.32.html>.

Richard

 

[Dan Pop]

I want to know what is wrong with alloca() ?

Is it hard to implement in a platform-independent way?
OR there is no need for it?

AFAIK alloca() /*(used to)*/ allocate memory at run-time from the
function stack, so that the programmer need not call free() to
de-allocate it.Since it automatically got freed when the function
returns, Right?

So what is wrong with implementing such a function..why doesn't the
Standard provide this function?

Whenever you have such questions, look up the (freely available) C
standard rationale document, first. ONLY if you find nothing there
ask here.

Some implementations provide a function (often called alloca) which
allocates the requested object from automatic storage; the object is
automatically freed when the calling function exits. Such a function
is not efficiently implementable in a variety of environments, so it
was not adopted in the Standard.

Dan

 

[Walter]

Both. RTFAQ: <http://www.eskimo.com/~scs/C-faq/q7.32.html>.

alloca can be tricky to implement correctly, as the FAQ points out. The
compilers I've used that did implement it all did implement it correctly,
even if there were already things on the stack like partial function
arguments. alloca is pretty handy for fast allocation of temporary buffers -
it's thread safe, exception safe, and the automatic cleanup is nice when a
function has complex logic with multiple exits.

I've had to port some code that used alloca to a system that couldn't
support it. The result usually was an uglification of the code, as a bunch
of code needed to be added to keep track of all the allocated bits so they
could be properly cleaned up.

Fortunately, I don't have to use that miserable system any more <g>, and I
regularly use alloca. It's portable to all the compilers I need to use. I
like alloca, and put it in the D programming language as well.

Sure, alloca is not in the C standard. But that standard specifies a minimum
standard, the realities of the compiler business are that alloca will be
supported if it is reasonably feasible to get it to work on the system.

-Walter
www.digitalmars.com free C/C++/D compilers

 

[Dan Pop]

alloca can be tricky to implement correctly, as the FAQ points out. The
compilers I've used that did implement it all did implement it correctly,
even if there were already things on the stack like partial function
arguments. alloca is pretty handy for fast allocation of temporary buffers -
it's thread safe, exception safe, and the automatic cleanup is nice when a
function has complex logic with multiple exits.

I've had to port some code that used alloca to a system that couldn't
support it. The result usually was an uglification of the code, as a bunch
of code needed to be added to keep track of all the allocated bits so they
could be properly cleaned up.

Fortunately, I don't have to use that miserable system any more <g>, and I
regularly use alloca. It's portable to all the compilers I need to use. I
like alloca, and put it in the D programming language as well.

Sure, alloca is not in the C standard. But that standard specifies a minimum
standard, the realities of the compiler business are that alloca will be
supported if it is reasonably feasible to get it to work on the system.

And, as you learned yourself, code relying on it will not be portable to
systems where alloca is not reasonably feasible. If none of the
implementors in the C committee had any problems supporting alloca, I am
reasonably convinced that it would have been part of the standard C
library. There was plenty of existing practice for alloca, at the time
C89 was drafted.

Likewise, the rather strange and arbitrary conditions imposed by the
standard to the usage of the setjmp macro (even H&S got them wrong,
in their example code) are the result of requests made by implementors,
who needed them in order to get this macro to work on their supported
platforms.

Dan

 

[LibraryUser]

I want to know what is wrong with alloca() ?

Is it hard to implement in a platform-independent way?
OR there is no need for it?

In addition to the other answers, it is effectively implemented
in C99, by the use of 'adjustable arrays'.

 

[Keith Thompson]

In addition to the other answers, it is effectively implemented
in C99, by the use of 'adjustable arrays'.

I think you mean variable length arrays (VLAs). The term 'adjustable
arrays' would imply that the length can be changed after the object is
created, a feature that VLAs don't support.

There are some differences. A VLA can only be created in a
declaration; alloca() can be called in the middle of an expression
(which can cause problems in function calls). Also, the number of
VLAs created in a given scope is fixed, whereas alloca() can be called
an arbitrary number of times. For example, a function using could
create a linked list of N alloca()-allocated nodes, where N is a
parameter; that can't be done with VLAs. (Well, maybe with some ugly
tricks involving recursion, but I'm not going to figure out how to do
it).