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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,8ecbc35ea893182f
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Alex R. Mosteo" <amosteo@unizar.es>
Newsgroups: comp.lang.ada
Subject: Re: Interfacing to C: big structures
Date: Thu, 28 Feb 2008 12:30:26 +0100
Message-ID: <62nkanF24b2toU1@mid.individual.net>
References: 
 <c48dc7da-6f04-4f0f-9a8f-e0acc371ee3c@o10g2000hsf.googlegroups.com>
 	<62idb0F23ddfnU1@mid.individual.net>
 <56a177e4-506f-4bc8-a531-7f2dd15d50c8@i7g2000prf.googlegroups.com>
 	<m27igr4i0b.fsf@mac.com>
 <21af9a6a-d522-4ba5-9d67-68eace9cd1b1@n77g2000hse.googlegroups.com>
Reply-To: alejandro@mosteo.com
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Trace: individual.net RD9kIR+Yqb6jidmRahOPGABhPxFQ/X3NAV6c/2fdcX4KqX2l0=
Cancel-Lock: sha1:bzV1qZdPxiGUbNuWce0//WmaJCg=
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
In-Reply-To: 
 <21af9a6a-d522-4ba5-9d67-68eace9cd1b1@n77g2000hse.googlegroups.com>
Xref: g2news1.google.com comp.lang.ada:20138
Date: 2008-02-28T12:30:26+01:00
List-Id: <comp.lang.ada>

Adam Beneschan wrote:
> On Feb 26, 11:47 am, Simon Wright <simon.j.wri...@mac.com> wrote:
>> Adam Beneschan <a...@irvine.com> writes:
>>> I thought of something like this, but Maciej said something about
>>> wanting to avoid dynamic memory, and it seems that you're defining a
>>> type whose size isn't going to be known until runtime, and therefore
>>> if you declare an Ada variable of that type, it will have to be
>>> allocated dynamically in some way.
>> That was the cunning trick: the size is known at *elaboration* time!
> 
> Isn't that part of "runtime"?  I'm not sure I get your point.  In the
> typical compile/link/execute model, as I understand it, the function
> that returns the size isn't going to be "called" by the linker, and
> probably not by the loader when the program is executed; so the
> function will be called when the program starts executing, which means
> that any objects of that type can't be allocated until after execution
> starts, which means "dynamic allocation" more or less by definition.
> However, as others have pointed out, it's not clear exactly what kinds
> of dynamic allocation need to be avoided here, and which ones might be
> OK.

Actually I would have expected these types to be allocated in the stack.
I likened them to indefinite types, but certainly the maximum size of
some indefinite types may be known at compile time, so this set them
apart and I was simplifying too much. Besides, at least one
implementation, as Randy Brukardt said, uses the heap for them. Even if
it's the compiler doing the management, this may be a no-go in some real
time environments.

Using the heap may be easier for an implementation; another question is
if it is still doable in the stack. I wonder what gnat does. Is the
secondary gnat stack considered a kind of heap? Is this what gnat uses?
Are there pragma Restrictions that could clarify this? Just throwing
questions in the air.

I guess that if my proposal is deemed unacceptable, one can neither use
anymore things like

type T (Len : Natural) is record
   Name   : String (1 .. Len);
   Others : Whatever;
   -- ...
end record;

?