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!22g2000hsm.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Wed, 12 Sep 2007 09:08:18 -0700 Organization: http://groups.google.com Message-ID: <1189613298.182273.23310@22g2000hsm.googlegroups.com> References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189524788.300591.312380@w3g2000hsg.googlegroups.com> <1189547814.740732.220140@x40g2000prg.googlegroups.com> <1189599757.106695.147440@57g2000hsv.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 1189613298 6136 127.0.0.1 (12 Sep 2007 16:08:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 12 Sep 2007 16:08:18 +0000 (UTC) In-Reply-To: <1189599757.106695.147440@57g2000hsv.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: 22g2000hsm.googlegroups.com; posting-host=66.126.103.122; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1913 Date: 2007-09-12T09:08:18-07:00 List-Id: On Sep 12, 5:22 am, Maciej Sobczak wrote: > On 11 Wrz, 23:56, Adam Beneschan wrote: > > > OK, I think I have one. GNAT compiles and runs it, although I haven't > > checked the language rules carefully to make sure it's legal. > > Without checking the language rules carefully, I think this is a legal > program demonstrating artificially broken design. > > Consider that there is no exception and instead you call > Unchecked_Deallocation after successfully creating the object. > The P pointer will be dangling. > > So what is your example proving? That we can make dangling pointers in > Ada? This is already known. You can create dangling pointers and do all sorts of other bad stuff by using "Unchecked" features like Unchecked_Deallocation, and other things like 'Address clauses. These are documented in the manual, and it's pointed out that the user needs to know what they're doing or else the result could be erroneous. But the language shouldn't be adding dangerous stuff like that automatically. Unchecked_Deallocation is called "Unchecked" for a very good reason, to remind those who use the routine that it could lead to trouble. But the language can't start doing such unchecked stuff itself automatically. Now, I'm aware that I used an Unchecked thing ('Unchecked_Access) in my example. So far, I haven't been able to create an example that doesn't. But I'd want a *proof* that it's impossible for the automatic deallocation you're asking for could not create a dangling pointer in the absence of Unchecked or other dangerous features, and I'm not yet convinced. (And your earlier statement that "the object simply does not exist" falls several miles short of a proof, and my example proves that that is wrong anyway, because the object does exist temporarily.) But you seem to be suggesting that the language should just do the "right thing" anyway (i.e. deallocate the object), and if a certain combination of legal features leads to a disaster like a dangling pointer, you throw up your hands and blame it on a broken design. That's the C++ way, not the Ada way. In Ada, safety is important. We try to make sure programs can't cause this sort of problem unless the user deliberately does something that is known to be dangerous. By the way, although I think having the language deallocate the object automatically is a bad idea, I do sympathize with the problem that it's impossible to get a hold of the access value that was already allocated so that you can do an Unchecked_Deallocation yourself. None of the workarounds seem all that good. Unfortunately, I can't think of a good way to add this to the language. -- Adam