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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ae395e5c11de7bc9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!33g2000yqj.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: segfault with large-ish array with GNAT Date: Thu, 18 Mar 2010 03:23:44 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <642ddf8b-1d45-4f74-83ad-2c755040ca33@k24g2000pro.googlegroups.com> <4ba13454$0$6720$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1268907824 5309 127.0.0.1 (18 Mar 2010 10:23:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 18 Mar 2010 10:23:44 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: 33g2000yqj.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:10617 Date: 2010-03-18T03:23:44-07:00 List-Id: Jeffrey Creem wrote on comp.lang.ada: > Jerry wrote: > > Thanks for the helpful comments. > > > So here's me being naive: I would have thought that Ada (or GNAT > > specifically) would be smart enough to allocate memory for large > > objects such as my long array in a transparent way so that I don't > > have to worry about it, thus (in the Ada spirit) making it harder to > > screw up. (Like not having to worry about whether arguments to > > subprograms are passed by value or by reference--it just happens.) > > > But it seems that I will have to allocate memory for large objects > > using pointers (and thus take the memory from the heap). Is that > > right? > > > In this context, is there any advantage to declaring the large object > > inside a declare block? Would that force the memory to be allocated > > from the heap? > > > Jerry > > If you want the memory to come from the heap, you need to declare the > variables inside of packages instead of inside procedures. You can then > avoid using access types. > > declare blocks will not help. > > As for wishing that the compiler would automatically switch between heap > and stack, that would probably be a terrible idea and render the > language quite unsuitable for embedded systems. > > -- warning, not even compiled early morning code example below > > package do_stuff is > =A0 =A0 procedure no_bomb; > end do_stuff; > > package body do_stuff is > =A0 =A0 =A0 type Float_Array_Type is array (Integer range <>) of Long_Flo= at; > =A0 =A0 =A0 -- 1_048_343 causes segmentation fault, 1_048_342 =A0does not= . > =A0 =A0 =A0 x : Float_Array_Type(1 .. 1_048_343); > > =A0 =A0 =A0procedure No_bomb is > > =A0 =A0 =A0begin > =A0 =A0 =A0 =A0x(1) :=3D 1.0; > =A0 =A0 =A0end No_bomb; > end do_stuff; > > with do_stuff; > procedure stuff is > > begin > =A0 =A0 do_stuff.No_Bomb; > end stuff; No, the array is not in the heap in this case; it is in the executable program's data segment. This may increase the size of the binary file. To ensure that the array is on the heap, it is necessary to use an access type and an allocator, e.g.: type Float_Array_Access_Type is access Float_Array_Type; x : Float_Array_Access_Type :=3D new Float_Array_Type (1 .. 1_048_343); -- Ludovic Brenta.