Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > alloca

Reply
Thread Tools

alloca

 
 
Harald van Dijk
Guest
Posts: n/a
 
      03-03-2008
On Mon, 03 Mar 2008 18:05:58 -0500, CBFalconer wrote:
> jacob navia wrote:
>> 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.


They never were portable in the sense that you use it.

> It is not even
> implementable in a portable manner.


It may require compiler help, but assuming compiler help is available,
it's implementable on every system. And if compiler help is not available,
then discussing implementation modifications is fairly meaningless.

> If I am right about this, you can't
> even give topical code for it on this newsgroup.


Of course, because any code he would give, even if in direct response to
your request in this newsgroup, would be discarded as nontopical.

You could've just stopped at "It is not mentioned because it does not
exist in standard C".
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-03-2008
Bartc wrote:
> "Eric Sosman" <(E-Mail Removed)> wrote
>>
>> 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.


The "embedded" alloca() carries a further danger: Machines
that pass function arguments on the same stack from which alloca()
obtains memory are likely to botch the argument list. Instead of

[ FILE* ]
[ size_t ]
[ char* ]

.... the function may receive a stack that looks like

[ FILE* ]
[ size_t ]
[ b ]
[ u ]
[ f ]
[ f ]
[ e ]
[ r ]
[ char* ]

.... with unwelcome consequences. In order to avoid this,
the compiler needs to special-case the handling of function
arguments involving alloca(), rewriting to something like

char *_temp = alloca(SIZE);
ptr = fgets(_temp, SIZE, stdin);

Jacob, does your compiler do this transformation, or
something similar?

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Bartc
Guest
Posts: n/a
 
      03-04-2008

"Eric Sosman" <(E-Mail Removed)> wrote in message
news:1204588027.704904@news1nwk...
> Bartc wrote:
>> "Eric Sosman" <(E-Mail Removed)> wrote
>>>
>>> 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);


> The "embedded" alloca() carries a further danger: Machines
> that pass function arguments on the same stack from which alloca()
> obtains memory are likely to botch the argument list. Instead of
>
> [ FILE* ]
> [ size_t ]
> [ char* ]
>
> ... the function may receive a stack that looks like
>
> [ FILE* ]
> [ size_t ]
> [ b ]
> [ u ]
> [ f ]
> [ f ]
> [ e ]
> [ r ]
> [ char* ]


Good answer. I was thinking of the equal likelihood of running out of stack
space.

> In order to avoid this,
> the compiler needs to special-case the handling of function
> arguments involving alloca(), rewriting to something like
>
> char *_temp = alloca(SIZE);
> ptr = fgets(_temp, SIZE, stdin);


I did a quick test [on lccwin32], function calls as arguments tend to be
dealt with separately from the actual parameter pushing, don't think
alloca() had special treatment.

--
Bart


 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-04-2008
In article <fqhrds$ln4$(E-Mail Removed)>,
Walter Roberson <(E-Mail Removed)-cnrc.gc.ca> wrote:

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


And yet people have written code that uses alloca() without the
slightest regard for the details of the ABI in use. They have
used it in portable code: not portable to every C implementation,
but portability is not absolute. If one wants to talk about alloca()
in general, then this is the place to do it.

-- Richard
--
:wq
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
Malcolm McLean <(E-Mail Removed)> wrote:

>Oddly enough alloca is on topic in comp.std.c, because that's the place to
>discuss proposed changes to the C standard.


Just because something isn't in the C standard doesn't mean that its
only interest to C programmers is as a proposed addition. alloca() is
used in existing C implementations, in code not intended for a single
system. Discussions of such subjects as how portable it is, and when
it's a good idea to use it, belong here.

-- Richard
--
:wq
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-04-2008
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.
> ...


Memory allocated by 'alloca' function obeys rather artificial non-C-ish
lifetime rules, which might easily lead to rather nasty surprises when
used without caution (did anyone mention newcomers?). In C99 language
VLAs provide support for run-time sized automatic memory, essentially
eliminating the need for 'alloca'.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Gordon Burditt
Guest
Posts: n/a
 
      03-04-2008
>This function is not mentioned very often in this newsgroup but it
>is a VERY useful function, implemented in most compilers.


And, unfortunately, *MIS*-implemented in many.

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


Disadvantages:

- In all the implementations I have seen, it does NOT make any attempt
to detect stack overflow and return NULL on error. This is a
serious problem, the gets() of memory allocation.
- There is no way to free memory except by exiting the function, which
means that alloca() called within a loop can accumulate a lot of
no-longer-used storage. Well, that's just a situation where malloc()
should be used rather than alloca().
- It is not a standard C function.
- alloca(), when implemented not as a wrapper for malloc() but actually
allocating storage on the stack, cannot work reliably if the compiler
does not know that alloca() is being called, otherwise, there is a
tendancy for it to allocate blocks of memory in the middle of function
parameter lists, causing garbage to be passed to functions.
This means that if you take the address of alloca(), put it in a function
pointer, and then call it indirectly, unless the compiler can figure
out that it might be a call to alloca(), it is likely to malfunction.
(gcc on FreeBSD makes taking the address of alloca() fail, probably
the best way to avoid this.)


Test your version of alloca():

- Put the program below into a file.
- Add whatever header is needed to declare alloca().
- Compile it and run it.
- Verify that the first line of output contains "1 = 1" and the
third line contains "2 = 2". If not, something failed.
- When reporting results, include your processor, OS, version, compiler,
and it's version, and what compiler flags you used.
- Try and see if there are any differences with different optimization flags.

Incidentally, on i386, FreeBSD 6.2 with gcc 3.4.6, it seems to use
32 bytes each for alloca(3). No optimization, -O, -O2, and -O3 all
produce correct results.

It's intended that in this test program, the number of alloca()
calls exceeds the number of registers the compiler can use to pass
function parameters. If that's not the case for your platform,
edit accordingly.

#include <stdlib.h>

int main(int argc, char **argv)
{
printf("1 = %d\n%p %p %p %p %p %p %p %p %p %p %p\n2 = %d\n",
1,
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
alloca(3),
2);
exit(EXIT_SUCCESS);
}
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-04-2008
In article <(E-Mail Removed)>,
CBFalconer <(E-Mail Removed)> wrote:

>It is not even implementable in a portable manner.


What does this mean? Is addition implementable in a portable manner?
Is switch? Is setjmp()?

Do you just mean it's hard to implement efficiently on some systems?

It's certainly *possible* to implement it on all systems: if all else
fails, use malloc(), and make the return code from functions that use
it do any necessary free()ing. You'd also need to make longjmp() more
complicated.

-- Richard
--
:wq
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-04-2008
Walter Roberson wrote:
> ...
> 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.


Sorry, but none of the standard library functions are required to be
writable in pure C (as opposed to relying on "the intimate details of
the ABI in use"). Something like this is not supposed to be used as a
criterion for library inclusion (or non-inclusion).

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-04-2008
Eric Sosman wrote:
> ...
> 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?
> ...


Today the above "rationale" is obviously incorrect. I'm not saying that
people who came up with this rationale were wrong. It is quite possible
that they were right at the time when they came up with it. However,
today the Variable Length Arrays (VLAs) are part of the C99 standard.
And the complexities of implementing VLAs are exactly the same (or even
more severe) than the difficulties that arise in implementation of
'alloca' function. Yet VLAs have made it into the standard.

Actually the real reason why we don't need to care about 'alloca'
anymore is the simple fact that its benefits are already provided by a
more C-like feature - VLAs.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable alloca() replacement? Freejack C Programming 9 01-19-2005 08:18 AM
Question about alloca() and alternative to using stack in an implementation Sushil C Programming 20 07-20-2004 01:38 PM
Why didn't ANSI/ISO make alloca() standard? Nitin Bhardwaj C Programming 6 07-17-2004 05:53 PM
gcc and alloca jacob navia C Programming 32 07-16-2004 06:59 PM



Advertisments