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: 103376,6b1a1ed8b075945
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!postnews.google.com!19g2000hsx.googlegroups.com!not-for-mail
From: Adam Beneschan <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Allocators and exceptions
Date: Mon, 10 Sep 2007 08:44:08 -0700
Organization: http://groups.google.com
Message-ID: <1189439048.467517.186160@19g2000hsx.googlegroups.com>
References: <1189323618.588340.87180@o80g2000hse.googlegroups.com>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Trace: posting.google.com 1189439049 16736 127.0.0.1 (10 Sep 2007 15:44:09
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 10 Sep 2007 15:44:09 +0000 (UTC)
In-Reply-To: <1189323618.588340.87180@o80g2000hse.googlegroups.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: 19g2000hsx.googlegroups.com; posting-host=66.126.103.122;
   posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0
Xref: g2news2.google.com comp.lang.ada:1863
Date: 2007-09-10T08:44:08-07:00
List-Id: <comp.lang.ada>

On Sep 9, 12:40 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> What happens when during the initialization of the newly allocated
> object an exception is raised?
>
> I cannot find anything in the AARM that covers this case. What I want
> to find exactly is the *guarantee* that the allocated memory is
> automatically reclaimed.
> Any relevant paragraph numbers are highly welcome.

I don't think this can be guaranteed, not as I read 4.8(10).  The
semantics of an allocator without an initializer is that the object is
created (that's the allocation), and then the components are
initialized.  If an exception raise occurs during the initialization
process, the object creation has already occurred, and there's nothing
that says that this is reversed.  In fact, I believe there is nowhere
in the language that says that memory is automatically reclaimed in
*any* situation; and, in fact, there is no guarantee that you can even
reclaim any storage at all.  13.11.2 defines Unchecked_Deallocation,
but this section has an "Implementation Advice" that says "For a
standard storage pool, Free [an instance of Unchecked_Deallocation]
should actually reclaim the storage."  Note that that is only
*advice*.  So an implementation can legitimately be an Ada compiler
without implementing Unchecked_Deallocation at all.  The message here,
I think, is that the Ada language has said that it doesn't worry about
storage reclamation; you have to worry about that yourself.

Anyway, if this is an issue, I'd write a function to perform the "new"
operation.  Using your later example:

   function new_T (Init : Integer) return T_Access is
   begin
      declare
         New_Rec : T (Init);
      begin
         return new T' (New_Rec);
      end;
   exception
      when others => ...
   end new_T;

Now any exceptions involved in initializing the record will get caught
before allocation takes place.  The allocator itself won't raise any
exceptions (other than Storage_Error), unless copying New_Rec to the
newly allocated object raises an exception, which could happen only if
there are controlled types involved and an Adjust routine raises an
exception, in which case you're in a whole bunch of trouble anyway.

                    -- Adam