From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3c61ad7f887cbc37 X-Google-Attributes: gid103376,public From: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: GNAT memory allocation Date: 1996/08/02 Message-ID: #1/1 X-Deja-AN: 171609462 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: <32013E73.33F8@isrc.sandia.gov> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-08-02T00:00:00+00:00 List-Id: Henry W. Schneiderman (hwschne@isrc.sandia.gov) wrote: : I've got a problem allocating memory using the GNAT Ada compiler v3.05 : on a Sun Sparc 10 w/ Solaris 2.4. When I declare large arrays (on the : order of 1 Meg) I get a core dump. It seems like the memory for these : large arrays is allocated from the stack. Is there a way force storage : of these arrays elsewhere in memory where there is more storage space -- : maybe something equivalent to the "static" statement in c? Are there : any pragmas that do this? Objects declared inside (only) packages, as opposed to subprograms, are equivalent to C's "static" -- they are allocated statically rather than on the stack. However, this presumes the size of the array is known at compile-time. If the size is not known at compile-time, the array may still end up on a "secondary" stack, or in the "heap," depending on the implementation. You can also explicitly allocate an array in the heap using "new". : Any help would be greatly appreciated! : -Henry Schneiderman : hwschne@isrc.sandia.gov or hws@cs.cmu.edu -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA