alloca

M

Morris Dovey

jacob said:
Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

Hmm. I won't raise hell, but I'll point out that it's as topical
here as GETMAIN or shmget().
 
J

jacob navia

This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

This means that the storage obtained can only be used within the scope
where this function was called, and can't be returned as the result of a
function call.

The syntax is:

void *alloca(size_t);

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

What makes this function interesting is that
o It is very efficient. Since it allocates from the stack,
a few assembler instructions are needed, much quicker
than most "malloc" implementations.
o The storage is freed automatically when the function where
it is called exits. No need to call free().

Caveats:

o As I said above, the storage can't be returned from the current
function.
o There is the risk of stack overflow if you allocate too much memory
with it. If it fails it returns NULL, but do not count on it.

Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.
 
K

Kenneth Brody

jacob said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

[Referring to "alloca" in the subject, but not the body.]
I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it. [...]
Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

Well, I find open(), select(), and socket() quite useful as well, and
they're available on every platform I use, but that doesn't make them
relevent to clc.

And, to your mention as to how wide-spread it's availablility is, here
is what happens on my Windows system, with MSVC:

==========
C:\temp>type usenet.c
#include <stdio.h>
#include <stdlib.h>

int main()
{
char *foo = alloca(100);
}

C:\temp>cl usenet.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

usenet.c
usenet.c(6) : warning C4047: 'initializing' : 'char *' differs in levels of indi
rection from 'int '
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:usenet.exe
usenet.obj
usenet.obj : error LNK2001: unresolved external symbol _alloca
usenet.exe : fatal error LNK1120: 1 unresolved externals

C:\temp>
==========

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
W

Walter Roberson

This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.
I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

I would say the opposite: that newcomers need to learn first
proper C, and only when they become well acquainted with proper C
should they being learning about non-standard implementation-dependant
functions.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

What stack?

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

If it is present in Unix, then you can point to the appropriate
opengroup.org man page?

The Linux system I have close at hand says,

CONFORMING TO
There is evidence that the alloca function appeared in 32v, pwb,
pwb.2, 3bsd, and 4bsd. There is a man page for it in BSD 4.3. Linux
uses the GNU version. This function is not in POSIX or SUSv3.
 
M

Michael Mair

jacob said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

This means that the storage obtained can only be used within the scope
where this function was called, and can't be returned as the result of a
function call.

The syntax is:

void *alloca(size_t);

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

What makes this function interesting is that
o It is very efficient. Since it allocates from the stack,
a few assembler instructions are needed, much quicker
than most "malloc" implementations.
o The storage is freed automatically when the function where
it is called exits. No need to call free().

Caveats:

o As I said above, the storage can't be returned from the current
function.
o There is the risk of stack overflow if you allocate too much memory
with it. If it fails it returns NULL, but do not count on it.

- the memory allocated with alloca() usually cannot be deallocated.
- the memory allocated with alloca() lives "till the end of the
Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard.

Nope, but I would raise hell if I found someone using it frivolously,
i.e. for convenience only, in production code. alloca() usually
bypasses application memory management and thus can produce funny
effects and memory sinks. If there is a good reason, e.g. "using
alloca() leads to significant speedup in foo() and consequently
the whole application while automatic storage duration memory
consumption can be at most X bytes / is small / has a fixed ratio
relative to Y", then using alloca() is okay, of course.
And no, "I use it always because it is fast as hell" does not cut it.
Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

.... you forgot the problem that, when they come to clc with problems,
they always get the "not in the Standard" treatment ;-)

Apart from that, knowing that there _is_ an alloca() (almost everywhere)
certainly is useful but knowing when (not) to use it is almost more
important.


Cheers
Michael
 
U

user923005

This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

This means that the storage obtained can only be used within the scope
where this function was called, and can't be returned as the result of a
function call.

The syntax is:

void *alloca(size_t);

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

What makes this function interesting is that
o It is very efficient. Since it allocates from the stack,
   a few assembler instructions are needed, much quicker
   than most "malloc" implementations.
o The storage is freed automatically when the function where
   it is called exits. No need to call free().

Caveats:

o As I said above, the storage can't be returned from the current
   function.
o There is the risk of stack overflow if you allocate too much memory
   with it.  If it fails it returns NULL, but do not count on it.

Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

There is no function called alloca() using Microsoft Visual C++,
although there is one called _alloca():
http://msdn2.microsoft.com/en-us/library/wb1s57t5(VS.71).aspx

Note that it throws {non-standard} exceptions rather than returning a
null pointer.
I guess that other versions of stack allocation functions behave
differently.
 
R

Richard Tobin

Kenneth Brody said:
Well, I find open(), select(), and socket() quite useful as well, and
they're available on every platform I use, but that doesn't make them
relevent to clc.

I disagree. I think alloca() is far more on-topic than those other
functions. They have a standard that specifies them, and newsgroups
related to that standard. alloca() on the other is just something
that's existed in most versions of C. If comp.lang.c is not the
newsgroup for it, what is?

-- Richard
 
M

Malcolm McLean

jacob navia said:
Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.
Oddly enough alloca is on topic in comp.std.c, because that's the place to
discuss proposed changes to the C standard.
However topicality should not be so tightly drawn that functions like
alloca() cannot be mentioned here at all. However it should be discussed as
it arises naturally in response to topical thread, not as a subject in its
own right.
 
E

Eric Sosman

jacob said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

This means that the storage obtained can only be used within the scope
where this function was called, and can't be returned as the result of a
function call.

The syntax is:

void *alloca(size_t);

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

What makes this function interesting is that
o It is very efficient. Since it allocates from the stack,
a few assembler instructions are needed, much quicker
than most "malloc" implementations.

That's odd: The Rationale says "Such a function is not
efficiently implementable in a variety of environments, so
it was not adopted in the Standard." What do you know that
the couple hundred contributors to the Standard didn't?
o The storage is freed automatically when the function where
it is called exits. No need to call free().

Caveats:

o As I said above, the storage can't be returned from the current
function.
o There is the risk of stack overflow if you allocate too much memory
with it. If it fails it returns NULL, but do not count on it.

You forgot

o Even on systems where alloca() is available, it may fail
catastrophically in some contexts, for example

ptr = fgets(alloca(SIZE), SIZE, stdin);
Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

My reason for raising hell is quite different: It is that
you are trying to fool "newcomers" with a supposedly-advantageous
function having only minor drawbacks. In actual fact, alloca()
offers *no* benefit over the mechanisms provided by the Standard.
Those mechanisms are also unsafe, but they are *less* so than
is alloca(). In short, alloca() just makes a dangerous situation
more dangerous without providing any compensatory benefit.
 
W

Walter Roberson

I disagree. I think alloca() is far more on-topic than those other
functions. They have a standard that specifies them, and newsgroups
related to that standard. alloca() on the other is just something
that's existed in most versions of C. If comp.lang.c is not the
newsgroup for it, what is?

It is not possible to write a general alloca() that exists
outside of the intimate details of the ABI in use. It therefore
must not be thought of as belonging to C: it belongs to the
system extensions that C compiler provides for that operating
environment. That makes it topical in the newsgroups that discuss
those operating environment specifics, not topical in comp.lang.c .

For example I would expect alloc() on SGI IRIX to be discussed
in comp.sys.sgi.misc .
 
L

lawrence.jones

jacob navia said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

It is a horrible hack that should generally be avoided, particularly by
novices. Many implementations are buggy and nearly all implementations
have restrictions on the contexts in which it can be used that are
documented poorly, if at all. It was left out of the C standard quite
intentionally. The variable length array feature of C99 was intended to
be a well-defined and well-behaved replacement for it.

-Larry Jones

No one can prove I did that!! -- Calvin
 
U

user923005

I disagree.  I think alloca() is far more on-topic than those other
functions.  They have a standard that specifies them, and newsgroups
related to that standard.  alloca() on the other is just something
that's existed in most versions of C.  If comp.lang.c is not the
newsgroup for it, what is?

I think if alloca() could be made to behave exactly like malloc(),
which is to say it should return a pointer to the memory if it
succeeds and a null pointer if it fails, then it would be quite a
useful addition. If this is not possible, then I think it has very
limited usefulness {who wants a standard function that behaves
differently every time you try to use it on a different platform or
with a different compiler?}. I suppose that the discussion would be
more sensible on than since we are
proposing adding something to the language, based on popular usage.
Follow-up set to
IMO-YMMV.
 
W

Walter Roberson

Out of Walter sayings?

That's been in my random signatures file since at least Oct 27, 2002.

The random Walter sayings are only a few weeks ago. I thought I'd put
in plenty of those, but it seems I'm posting more frequently than I
thought. I may have to dig out some more.
 
D

David Resnick

This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.

This function is an allocation function, i.e. it is similar in
functionality to the malloc() function, but it has the advantage of
allocating from the stack instead of allocating from the heap.

This means that the storage obtained can only be used within the scope
where this function was called, and can't be returned as the result of a
function call.

The syntax is:

void *alloca(size_t);

It is not a function mentioned in the C standard, but it is
present under unix, windows and Mac, (all compilers) and
in most C implementations actually.

What makes this function interesting is that
o It is very efficient. Since it allocates from the stack,
a few assembler instructions are needed, much quicker
than most "malloc" implementations.
o The storage is freed automatically when the function where
it is called exits. No need to call free().

Caveats:

o As I said above, the storage can't be returned from the current
function.
o There is the risk of stack overflow if you allocate too much memory
with it. If it fails it returns NULL, but do not count on it.

Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

I'm amazed that you post this drivel. I guess you just like
attention, and don't mind publicly attaching your name to really bad
advice. Regardless of one's opinions on topicality or lack thereof of
alloca, encouraging beginners (or experienced developers for that
matter) to make a habit of using alloca is a foolish. The advantages
you give are trivial ones compared to the risks -- efficiency can be
achieved by other means such as custom memory allocation strategies,
and calling free isn't really that hard. And the disadvantages are
impossible to guard against. I'll let the man page on my system have
the last word (perhaps you'd say it was written by one of the
"clique").

*****************
The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack overflow.
Thus, there is no NULL error return.

BUGS
The alloca function is machine and compiler dependent. On many
systems its implementation is buggy. Its use is discouraged.

On many systems alloca cannot be used inside the list of
arguments of a function call, because the stack space reserved by
alloca would appear on the stack in the middle of the space for the
function arguments.
**********************

-David
 
C

Charlton Wilbur

WR> It is not possible to write a general alloca() that exists
WR> outside of the intimate details of the ABI in use. It
WR> therefore must not be thought of as belonging to C: it belongs
WR> to the system extensions that C compiler provides for that
WR> operating environment.

While I concur that alloca() ought to be discussed in
compiler-specific newsgroups, I think your reasoning is suspect. It
is likewise impossible to write a general malloc() that exists outside
of the intimate details of the ABI in use, and yet that belongs to C,
and is frequently discussed here.

alloca() is about as standard as gotoxy() or getch(); different
compilers and libraries implement it differently or not at all, and so
it doesn't belong in comp.lang.c, but in the newsgroup or other forum
for the compiler in question.

Charlton
 
J

jacob navia

Kenneth said:
jacob said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

[Referring to "alloca" in the subject, but not the body.]
I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it. [...]
Some people in this newsgroup will raise hell because it is a function
not mentioned in the standard. Since this is not comp.std.c I really do
not care, and I think that new users should be aware of its existence,
and the possible advantages and problems with its usage.

Well, I find open(), select(), and socket() quite useful as well, and
they're available on every platform I use, but that doesn't make them
relevent to clc.

And, to your mention as to how wide-spread it's availablility is, here
is what happens on my Windows system, with MSVC:

==========
C:\temp>type usenet.c
#include <stdio.h>
#include <stdlib.h>

int main()
{
char *foo = alloca(100);
}

C:\temp>cl usenet.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

usenet.c
usenet.c(6) : warning C4047: 'initializing' : 'char *' differs in levels of indi
rection from 'int '
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:usenet.exe
usenet.obj
usenet.obj : error LNK2001: unresolved external symbol _alloca
usenet.exe : fatal error LNK1120: 1 unresolved externals

C:\temp>
==========

Hi Kenneth
1) Microsoft calls this function _alloca and NOT alloca.
It is declared in malloc.h (or in my 64 bit version)
in intrin.h

2) This is since at least 10 years.
 
W

Walter Roberson

1) Microsoft calls this function _alloca and NOT alloca.

Mmmm, but still

??

That is, even though microsoft calls the function _alloca
the microsoft user would still call alloca (no underscore)?
If that is not the case, if the user has to call (e.g.,) _alloca
then your "The syntax is" is not accurate. But that would
appear to contradict your assertions of how widespread and
portable it is.

Sorry but my head is starting to hurt, trying to come up with
ways that you could -somehow- be correct -and- not have
contradicted yourself...
 
B

Bartc

Eric Sosman said:
jacob said:
This function [alloca] is not mentioned very often in this newsgroup but
it
is a VERY useful function, implemented in most compilers.

I think it is useful to point to it since many people that read this
newsgroup are newcomers, and they could benefit by using it.
o As I said above, the storage can't be returned from the current
function.
o There is the risk of stack overflow if you allocate too much memory
with it. If it fails it returns NULL, but do not count on it.

You forgot

o Even on systems where alloca() is available, it may fail
catastrophically in some contexts, for example

ptr = fgets(alloca(SIZE), SIZE, stdin);

Why should that failure be any more likely than:

void fn()
{char buffer[SIZE];
....
ptr = fgets(buffer, SIZE, stdin);

If the implementation uses a stack for alloca() and for local variables,
then it seems stack overflow is equally likely.

(In fact alloca() may make overflow less likely, in a chain of function
calls, by not unconditionally allocating frame data, only as needed, and of
the size needed.)
 
C

CBFalconer

jacob said:
This function is not mentioned very often in this newsgroup but it
is a VERY useful function, implemented in most compilers.

It is not mentioned because it does not exist in standard C, and
programs calling it are no longer portable. It is not even
implementable in a portable manner. If I am right about this, you
can't even give topical code for it on this newsgroup.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top