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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b2dd3ff35d68d825 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-09 12:50:31 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!82-43-33-254.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: Unchecked_Deallocation subtleties Date: Wed, 09 Apr 2003 20:50:34 +0100 Organization: ThoughtWing Computer Software Message-ID: References: NNTP-Posting-Host: 82-43-33-254.cable.ubr01.croy.blueyonder.co.uk (82.43.33.254) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed X-Trace: fu-berlin.de 1049917830 10691303 82.43.33.254 (16 [25716]) In-Reply-To: User-Agent: Opera7.03/Win32 M2 build 2670 Xref: archiver1.google.com comp.lang.ada:36030 Date: 2003-04-09T20:50:34+01:00 List-Id: On Wed, 9 Apr 2003 09:10:21 +0000 (UTC), Piotr Zgorecki wrote: > I have a problem with interpretation of ARM 13.11.2(8): > > "Free(X), when X is already equal to null, has no effect." > > I'm looking at an implementation which will call user-defined > Deallocate, whether X is null or not. Is it correct? I believe this implementation is 'right'. It is certainly right if the module which contains the user-defined deallocation also chooses the representation(s) of a null pointer. Generally, is will be for the user- defined Deallocate to test if the access value is null, and do nothing (as the RM specifies) if it is. > I would suppose 'has no effect' means that Deallocate > shouldn't be called, because it can potentially have > side effects. To my mind it simply means that the user-defined implementation of Deallocate should behave in the way required by the RM if it is intended to obey the standard (for example being part of a product that will be sold on the understanding that it conforms to the standard). Do not be confused. The RM itself states that conforming implementations of Ada are permitted to have modes which do not conform. Furthermore, only a maniacal pedant would prefer an implementation which conforms over one which does exactly what the user actually requires (for a particular application). Regardless of whether it conforms to the standard or not, the only thing that a user-defined Deallocate -- or indeed any other implementation of a language feature -- really /should/ do is whatever is specified and required. If conforming to the standard is specified, an implementation should do what the RM says; on the other hand, if ringing a bell every time Deallocate is called is specified, then that is what the implementation should do. > Life would be easier if ARM had 'no effect' stuff strictly defined. I think the RM often tries to be too exact about a lot of things, and is too vague (as a result of overcomplexity) about some things. A programming language is a tool to do a job; it is not a religion or a law system. It is very good to define (and enforce) a standard in a way that enables real-life programs in practice to be ported very easily between implementations, but it is a waste of effort to try to circumscribe implementations any further than that. Presumably the Ada compiler that NASA uses for the Space Shuttle's flight software will not (and should not) be quite the same as the Ada compiler I use for my train set controller. Just my $0.02091 worth (inflation adjusted). -- Nick Roberts Jabber: debater@charente.de [ICQ: 159718630]