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: a07f3367d7,aa14979d20ba3045
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!postnews.google.com!p4g2000vba.googlegroups.com!not-for-mail
From: Ludovic Brenta <ludovic@ludovic-brenta.org>
Newsgroups: comp.lang.ada
Subject: Re: Allocation question
Date: Mon, 11 May 2009 03:40:54 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <54897f26-0d3f-421e-9426-1822a531674e@p4g2000vba.googlegroups.com>
References: <4a07fc7a$0$2855$ba620e4c@news.skynet.be>
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 1242038455 9676 127.0.0.1 (11 May 2009 10:40:55
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 11 May 2009 10:40:55 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: p4g2000vba.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.0.10)
	Gecko/2009042316 Firefox/3.0.10,gzip(gfe),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:5753
Date: 2009-05-11T03:40:54-07:00
List-Id: <comp.lang.ada>

On May 11, 12:23=A0pm, Olivier Scalbert <olivier.scalb...@algosyn.com>
wrote:
> procedure Test_Image is
> =A0 =A0 =A0Image : Image_T(1..100, 1..100);
> =A0 =A0 =A0FillColor : constant Color_T :=3D (0, 0, 0);
> begin
> =A0 =A0 =A0Fill(Image, FillColor);
> end Test_Image;
>
> This program seems to work.
> However when I increase the size of Image, I get a Segmentation fault.
>
> Should I need to play with access type and allocation stuff ?

Yes. Your image is on the stack. You can increase the size of the
stack up to an operating-system-dependent maximum (see ulimit(1) on
Unix-like systems) but there is always a limit. For potentially very
large objects, I think the better approach is to allocate them on the
heap. I would suggest you hide the allocation and deallocation inside
a controlled object which you declare on the stack, e.g.

private with Ada.Finalization;
package Image is
   type Image_T (Width, Height : Natural :=3D 0) is private;
private
   type Data_T is array(Positive range <>, Positive range <>) of
Color_T;
   type Data_Access_T is access Data_T;
   type Image_T (Width, Height : Natural) is
     new Ada.Finalization.Controlled with record
      Data : Data_Access_T;
   end record;
   overriding procedure Initialize (Object : in out Image_T); --
allocates
   overriding procedure Adjust(Object : in out Image_T); -- duplicates
Data.all?
   overriding procedure Finalize(Object : in out Image_T); --
deallocates
end Image;

with Image;
declare
   Im1 : Image.Image_T (1 .. 1024, 1 .. 1024); -- calls Initialize
which allocates
   Im2 : Image.Image_T (0, 0); -- calls Initialize which does nothing
begin
   Im2 :=3D Im1; -- calls Finalize (Im2) then Adjust (Im2)
end; -- calls Finalize for both

You may also share image data between objects.

For even larger objects you can make Initialize, Adjust and Finalize
much more sophisticated and store parts of the object on the heap and
part on disk. You would do that only if you think you can beat the
performance of your kernel's paging subsystem.

HTH

--
Ludovic Brenta.