Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   alloca (http://www.velocityreviews.com/forums/t595805-alloca.html)

Morris Dovey 03-03-2008 08:18 PM

Re: alloca [OT]
 
jacob navia wrote:

> 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().

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

jacob navia 03-03-2008 08:50 PM

alloca
 
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.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Kenneth Brody 03-03-2008 09:15 PM

Re: alloca
 
jacob navia wrote:
>
> 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:ThisIsASpamTrap@gmail.com>


Walter Roberson 03-03-2008 09:17 PM

Re: alloca
 
In article <fqhoa9$a68$1@aioe.org>, jacob navia <jacob@nospam.org> wrote:
>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.

--
"Pray do not take the pains / To set me right. /
In vain my faults ye quote; / I wrote as others wrote /
On Sunium's hight." -- Walter Savage Landor

Michael Mair 03-03-2008 09:21 PM

Re: alloca
 
jacob navia wrote:
> 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
function" -- always; see <fqh3hp02090@news3.newsguy.com> for a
very recent explanation why this can be bad.

> 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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

user923005 03-03-2008 09:26 PM

Re: alloca
 
On Mar 3, 12:50*pm, jacob navia <ja...@nospam.com> wrote:
> 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/lib...t5(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.

Richard Tobin 03-03-2008 09:36 PM

Re: alloca
 
In article <47CC6A8C.128ACDAC@spamcop.net>,
Kenneth Brody <kenbrody@spamcop.net> wrote:

>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
--
:wq

Malcolm McLean 03-03-2008 09:40 PM

Re: alloca
 

"jacob navia" <jacob@nospam.com> wrote in message
news:fqhoa9$a68$1@aioe.org...
> 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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


Eric Sosman 03-03-2008 09:40 PM

Re: alloca
 
jacob navia wrote:
> 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.

--
Eric.Sosman@sun.com

Walter Roberson 03-03-2008 09:43 PM

Re: alloca
 
In article <fqhr0p$1l4t$4@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:
>In article <47CC6A8C.128ACDAC@spamcop.net>,
>Kenneth Brody <kenbrody@spamcop.net> wrote:


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


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 .
--
So you found your solution
What will be your last contribution?
-- Supertramp (Fool's Overture)


All times are GMT. The time now is 05:56 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.