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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,42a57c8ee023f14d
X-Google-Attributes: gid103376,public
From: Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de>
Subject: Re: Q: memory management
Date: 1996/06/17
Message-ID: <uvvu3wa61g3.fsf@chaq.informatik.uni-tuebingen.de>#1/1
X-Deja-AN: 160613522
sender: haugha@chaq.informatik.uni-tuebingen.de
references: <uvvafy3ucoc.fsf@chaq.informatik.uni-tuebingen.de>
organization: Uni Tuebingen
newsgroups: comp.lang.ada
Date: 1996-06-17T00:00:00+00:00
List-Id: <comp.lang.ada>


Hi,

>>>>> "TT" == Tucker Taft <stt@henning.camb.inmet.com> writes:

    TT> Does the size vary from one allocation to the next, or are
    TT> they all the same size?

the sizes vary.

    [...]

    TT> This should work.  The storage pool would be specified via
    TT> Some_Access_Type'Storage_Pool where Some_Access_Type is any
    TT> access type declared at the library level.  It would be safest
    TT> if the access type had an unconstrained designated subtype,
    TT> such as:

    TT>      type Some_Access_Type is access all String;

    TT> to avoid the implementation-chosen storage pool from being one
    TT> that only works on access collections of uniformly-sized
    TT> objects.

Thanks. I'll try it.

    TT> If you are interfacing with C, then using "malloc" via a
    TT> pragma Import makes sense.  If you are interfacing with
    TT> assembler, it seems silly to drag in the C run-time support,
    TT> unless you know it will already be there for other reasons.

I have to interface to C and assembler. But even in the C case the
use of malloc looks silly to me.

 -hannes