comp.lang.ada
 help / color / mirror / Atom feed
From: Jeffrey Creem <jeff@thecreems.com>
Subject: Re: segfault with large-ish array with GNAT
Date: Thu, 18 Mar 2010 06:13:18 -0400
Date: 2010-03-18T06:13:18-04:00	[thread overview]
Message-ID: <rua977-kl7.ln1@newserver.thecreems.com> (raw)
In-Reply-To: <ac4bed10-f655-4fa5-8891-2967ba4388a0@k6g2000prg.googlegroups.com>

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
    procedure no_bomb;
end do_stuff;

package body do_stuff is
      type Float_Array_Type is array (Integer range <>) of Long_Float;
      -- 1_048_343 causes segmentation fault, 1_048_342  does not.
      x : Float_Array_Type(1 .. 1_048_343);

     procedure No_bomb is

     begin
       x(1) := 1.0;
     end No_bomb;
end do_stuff;


with do_stuff;
procedure stuff is

begin
    do_stuff.No_Bomb;
end stuff;





  parent reply	other threads:[~2010-03-18 10:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17 19:21 segfault with large-ish array with GNAT Jerry
2010-03-17 19:36 ` Gautier write-only
2010-03-17 19:58   ` Georg Bauhaus
2010-03-18  6:45     ` Jerry
2010-03-18  7:52       ` Ludovic Brenta
2010-03-18 23:57         ` Robert A Duff
2010-03-18 10:13       ` Jeffrey Creem [this message]
2010-03-18 10:23         ` Ludovic Brenta
2010-03-19  0:44           ` Jerry
2010-03-18 19:51         ` Adam Beneschan
2010-03-18 14:44       ` John B. Matthews
2010-03-19  4:44         ` Jeffrey R. Carter
2010-03-19  8:14           ` John B. Matthews
2010-03-18 15:36       ` Gautier write-only
2010-03-18 16:46       ` tmoran
2010-03-18 19:11         ` Warren
2010-03-18 17:03       ` Warren
2010-03-18 20:38         ` Maciej Sobczak
2010-03-19 13:26           ` Charmed Snark
2010-03-19 17:27             ` tmoran
2010-03-19 18:02               ` Simon Wright
2010-03-19 20:10                 ` Warren
2010-03-19 21:50                 ` Adam Beneschan
2010-03-19 20:24               ` Warren
2010-03-19 20:38           ` Warren
2010-03-19  8:31         ` Ludovic Brenta
2010-03-19 13:20           ` Warren
2010-03-19 12:04       ` Brian Drummond
2010-03-19 19:22         ` Jerry
2010-03-19 20:22         ` Jeffrey R. Carter
2010-03-19 23:24           ` Jerry
2010-03-20  0:25             ` Jeffrey R. Carter
2010-05-07 21:58       ` Raising the stack limit (was: segfault with large-ish array with GNAT) Björn Persson
2010-03-17 19:57 ` segfault with large-ish array with GNAT jonathan
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox