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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsgate.cuhk.edu.hk!news.netfront.net!not-for-mail From: "Jeffrey R. Carter" Newsgroups: comp.lang.ada Subject: Re: Reference counting and idempotent finalize Date: Thu, 12 Sep 2013 10:03:04 -0700 Organization: Netfront http://www.netfront.net/ Message-ID: References: NNTP-Posting-Host: 24.73.142.22 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: adenine.netfront.net 1379005385 40647 24.73.142.22 (12 Sep 2013 17:03:05 GMT) X-Complaints-To: news@netfront.net NNTP-Posting-Date: Thu, 12 Sep 2013 17:03:05 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: X-Original-Bytes: 2768 Xref: number.nntp.dca.giganews.com comp.lang.ada:183350 Date: 2013-09-12T10:03:04-07:00 List-Id: On 09/11/2013 10:05 PM, Natasha Kerensikova wrote: > > If Counter is already zero, a range check fails, an exception is > propagated, and the world ends. > > A negative value of Counter would mean something is seriously wrong with > the compiler or the memory has been corrupted. If I can't trust a > variable to be within the range defined for its type, I probably can't > trust the system to perform any meaningful computation. I check to ensure that the exception doesn't occur not because I don't trust the compiler, or even memory, but to protect against future, incorrect modifications, which I have encountered often enough in the past to worry about. This is why my code often checks a Natural for "<= 0", even though that can't happen; it's a habit I developed over 30 yrs ago in inferior languages. > I genuinely don't see any difference between this and my code, except > for my range check (but if it fails I do want the world to end), and > that you cover the possibility of Unchecked_Deallocation not setting the > access to null. Is this really possible? No. The postcondition for UD is "X = null", and the 1st Ada compiler I used apparently implemented UD as "begin X := null; end;". In my case, this is another unnecessarily defensive idiom. The postcondition for Finalize is "Item.Ptr = null" and I make sure of that, even if UD misbehaves. Your version could leave Self.Access_Value non-null if the decrement fails. In practice they're the same; in theory, not. -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python and the Holy Grail --- news://freenews.netfront.net/ - complaints: news@netfront.net ---