Re: Interfacing to C: big structures

"Alex R. Mosteo" <amosteo@[EMAIL PROTECTED]
> 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.

- Bob