Re: Interfacing to C: big structures

["Alex R. Mosteo" <amosteo@unizar.es>]

Robert A Duff wrote:
> "Alex R. Mosteo" <amosteo@unizar.es> writes:
> 
>> Actually I would have expected these types to be allocated in the stack.
> 
> Me, too.
> 
>> 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; ...
> 
> Yes.
> 
>> ...another question is
>> if it is still doable in the stack.
> 
> Yes, it is doable.
> 
>> ...I wonder what gnat does.
> 
> Puts it on the primary stack.
> 
>> ...Is the
>> secondary gnat stack considered a kind of heap?
> 
> No.  It's a stack.
> 
>> ...Is this what gnat uses?
> 
> No.  The secondary stack is for objects of unknown size that
> are returned as function results.  I think GNAT also uses
> it in some other cases, such as records containing
> controlled parts.
> 
>> Are there pragma Restrictions that could clarify this?
> 
> You can say:
> 
>     pragma Restrictions (No_Implicit_Heap_Allocations);
> 
>> ...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;
> 
> There are certainly cases where the above should not be used with
> "Len => <dynamic expression>", because it prevents you from
> calculating the maximum stack size for each task.  Or, you can
> calculate it, but the answer is "the size of the address space",
> which isn't very useful.
> 
> It might be OK if you change Natural to a range 1..100.

Thanks for that great a deal of information!