maximum number of variables?

Bob Rossi bob@brasko.net
Wed Aug 31 11:17:00 GMT 2005


On Wed, Aug 31, 2005 at 11:13:00AM +0200, Miguel A. Nu?ez wrote:
> 
> 
> ILT> Bob Rossi <bob@brasko.net> writes:
> 
> >> On Tue, Aug 30, 2005 at 10:54:02PM +0100, Lexington Luthor wrote:
> >> 
> >> > I think for large arrays, its best to allocate them from the heap. Use
> >> > malloc() or new (if using C++).
> >> 
> >> I've always been told that the heap and stack grow towards each other.
> >> If this is true, why would it be OK to create the item on the heap, vs
> >> on the stack? If it's not true, could someone simply explain how this
> >> works?
> 
> ILT> You are correct in theory.  In practice the heap and stack have
> ILT> different limits, and the limit on the heap is much larger than the
> ILT> stack (if running bash, compare ulimit -s and ulimit -v).  And if you
> ILT> worry about portability, on some platforms allocating a large stack
> ILT> frame will simply fail, and on some other platforms it will require
> ILT> extra work to emit stack probes to tell the OS that you are
> ILT> intentionally extending the stack rather than just referencing a
> ILT> random memory address.
> 
> ILT> Ian
> 
> 
> Ian,
> 
>   I did ulimit -s and ulimit -v in a solaris 9 sun machine. ulimit -s returns 8192, ok, but ulimit -s returns unlimited. Does this make sense?

Assumming you mean ulimit -s = 8192 and ulimit -v  = unlimited, then
yes, I suppose that makes sense. On my linux machine, ulimit -s and
ulimit -v = unlimited. In this case, I suppose it's possible that if the
array was on the stack and things borked, it would also bork when on the
heap. However, in your case, I know understand why things would work for
you if you moved from the stack to the heap.

Bob Rossi



More information about the Gcc-help mailing list