Solved

alloca()

Posted on 2003-11-25
6
251 Views
Last Modified: 2010-04-15

I was debuggin some old code in my project and come across the following lines of code.

            void* _obj;
           _obj = alloca(32768); /* Trick to make the compiler not to mess up with stackframs */

Does it make any sense to any of you ? Is it 64bit safe on solaris ?

Regards,
Lucky.
0
Comment
Question by:ylucki
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
  • 2
6 Comments
 
LVL 45

Expert Comment

by:Kent Olsen
ID: 9817476

It would be interesting to see how _obj is used later in the function.  :)

By reserving space on the stack instead of the heap, the programmer is ensuring that the buffer will always get free()d when the function exits.  Resetting the stack pointer when the function exits is just a couple of instructions and therefore very, very fast.  Executing the free() function is much slower.

So by using alloca() instead of malloc() the programmer is writing a function that can not possibly have a memory leak (which can greatly simplify some functions) and will have a shorter run time.

But unless I were coding a VERY time-critical operation I would stay away from this kind of practice.

Kent
0
 
LVL 1

Author Comment

by:ylucki
ID: 9829693

Well..yup !! It is very time-critical operation.
But _obj is not used any where in the function, after allocating memory.

I just wonder what the significance of 32768 here could be. Is it 64bit safe on solaris ?

Actually my application crashes when run in 64-bit mode. I just wonder if this could be one of the reasons.

-Lucky
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 9830645
As I see it, the only reason to use alloca is if the size to be allocated is variable.

Using....
--------8<--------
{
            void* _obj;
           _obj = alloca(32768); /* Trick to make the compiler not to mess up with stackframs */
}
--------8<--------
...is inherently slower than...
--------8<--------
{
char _obj[32768];
}
--------8<--------
...because the alloca function needs to do a lot of inline messing around (e.g. saving the stack pointer - I've not looked at the GCC disassembly of this but that's certainly true of Visual C's _alloca implementation - and certainly a function call anyhow). There is no need to use it if you are alloca-ing a constant amount of stack.

Your crash could be because you ran out of stack as a consequence of putting too much data onto it. Unlike the heap, stack size is a fixed allocation predetermined when your program is linked in Windows, predetermined by the kernel in Linux for normal applications (see _STK_LIM in /usr/src/linux/include/linux/sched.h) or determined when a thread is created by the attributes passed to pthread_create if you are using POSIX threads. When you run out of stack space, your program goes kaboom.

Disclaimer: I only recently became aware of alloca. The opinions stated here are those of an over-opinionated newbie :-)
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 45

Accepted Solution

by:
Kent Olsen earned 50 total points
ID: 9832177

Ok.  The fact that _obj isn't used anywhere in the function is curious.  Add in the fact that the comment associated with the alloca() function call says that this is a compiler trick and that 32768 is 0x80 (MIN_INTEGER on a 16-bit machine).

There's something "funny" with the call in that it appears to take advantage of a trick available on the original platform.

Try taking the alloca() statement out of the code and seeing what happens.


Kent
0
 
LVL 17

Expert Comment

by:rstaveley
ID: 9832250
Good point - it bypasses half of the space addressable by SS:SP in DOS-ville of you increment SP by that amount, if SS is unaltered. [0x8000]
0
 
LVL 1

Author Comment

by:ylucki
ID: 9834869

thanks for the information !

well....i would love to modify the code....but it is generated code and we don't have control on the code :-(

will update if something pops up in our further investigation !

thanks,
-lucky.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

An Outlet in Cocoa is a persistent reference to a GUI control; it connects a property (a variable) to a control.  For example, it is common to create an Outlet for the text field GUI control and change the text that appears in this field via that Ou…
Preface I don't like visual development tools that are supposed to write a program for me. Even if it is Xcode and I can use Interface Builder. Yes, it is a perfect tool and has helped me a lot, mainly, in the beginning, when my programs were small…
The goal of this video is to provide viewers with basic examples to understand and use pointers in the C programming language.
The goal of this video is to provide viewers with basic examples to understand how to use strings and some functions related to them in the C programming language.
Suggested Courses

751 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question