From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-21362-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 29657 invoked by alias); 31 Aug 2005 04:20:14 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 29520 invoked by uid 22791); 31 Aug 2005 04:19:28 -0000
Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180)
    by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Wed, 31 Aug 2005 04:19:28 +0000
Received: (qmail 24867 invoked by uid 10); 31 Aug 2005 04:19:26 -0000
Received: (qmail 30285 invoked by uid 500); 31 Aug 2005 04:19:19 -0000
Mail-Followup-To: lexington.luthor@gmail.com,
  gcc-help@gcc.gnu.org,
  bob@brasko.net
To: Bob Rossi <bob@brasko.net>
Cc: Lexington Luthor <lexington.luthor@gmail.com>, gcc-help@gcc.gnu.org
Subject: Re: maximum number of variables?
References: <20050830210651.GA1358@white>
	<BAY108-F34C227C39C44E98BB91A96B3AE0@phx.gbl>
	<df2khq$8mr$1@sea.gmane.org> <20050831010044.GA2661@white>
From: Ian Lance Taylor <ian@airs.com>
Date: Wed, 31 Aug 2005 04:20:00 -0000
In-Reply-To: <20050831010044.GA2661@white>
Message-ID: <m364tmn3g8.fsf@gossamer.airs.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2005-08/txt/msg00320.txt.bz2

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?

You are correct in theory.  In practice the heap and stack have
different limits, and the limit on the heap is much larger than the
stack (if running bash, compare ulimit -s and ulimit -v).  And if you
worry about portability, on some platforms allocating a large stack
frame will simply fail, and on some other platforms it will require
extra work to emit stack probes to tell the OS that you are
intentionally extending the stack rather than just referencing a
random memory address.

Ian