l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2002 Jul 16 21:40

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] dyanamic memory panacea
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] dyanamic memory panacea



On Tue, 16 Jul 2002, Peter Jay Salzman wrote:

> ok, not a panacea, but pretty cool nevertheless...
> 
> i was doing some reading and found a function alloca() which allocates
> dynamic memory like malloc() and friends, but it gets memory from the
> current stack frame instead of the heap.
> 
> the obvious advantage is that the memory is deallocated once the stack
> frame is popped.  in other words, when the function returns, all memory
> allocated by alloca is freed.  this means no memory leaks.  very cool.
> 
> however, in the man page, under BUGS, it says:
> 
> BUGS
>        The alloca function is machine dependent.
> 
> this doesn't say anything to me.  what does it mean for a function to be
> machine dependent?   does it behave differently across different
> machine architectures?  does code compiled on one x86 machine not run on
> another x86 machine?
> 
> what exactly is the man page warning me about?

Stack implementation in general is dependent on the hardware.  Some stacks
go from low memory to high memory. There are sometimes limited facilities
for manipulating stack pointers, so assembly language tricks of varying
levels of sophistication are always needed to implement alloca. (Similar
tricks are required for setjmp/longjmp.) Some stacks have limited ability
to expand... and this is probably the most critical hardware-specific
concern.

The warning is simply that there is no portability guarantee for this
function, and no guarantee that it can even be implemented on all
architectures, current or future.  I think it would be difficult for the
x86 architecture to evolve in a direction that would make implementing it
impossible, though, and I can't think of any hardware that a Un*x-ish OS
would run on that couldn't implement this function. 

Personally, I doubt I would find much use for it, though.  I am
uncomfortable allocating an input-determined amount of memory on the
stack.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------

_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.