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,5dacec64c8c879fa X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.135.231 with SMTP id pv7mr198128pbb.8.1328755762060; Wed, 08 Feb 2012 18:49:22 -0800 (PST) MIME-Version: 1.0 Path: wr5ni3356pbc.0!nntp.google.com!news2.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Preventing Unchecked_Deallocation? Date: Wed, 8 Feb 2012 20:49:14 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.googlegroups.com> <4350713b-6ac3-4b22-b221-8da2bac52fea@t5g2000yqk.googlegroups.com> <26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1328755759 1434 69.95.181.76 (9 Feb 2012 02:49:19 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 9 Feb 2012 02:49:19 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2012-02-08T20:49:14-06:00 List-Id: "Simon Belmont" wrote in message news:26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com... >I agree with all your points, and was essentially looking for a way to >enforce this at compile time. One way to do this is to use the Restriction (No_Dependence => Unchecked_Deallocation), but that of course will prevent anyone from using it, which might be going too far. (But not if you are using Ada 2012 subpools for storage management.) > I have casually looked at the implicit > dereferencing in 2012, but from a once-over it seems like it can only > be for visible parts (i.e. access discriminents); the problem is that > the implicit dereference doesn't stop you from explicit dereference, > and you can then cast away any sort of anonymity, constness, or not- > nullness. The entire point is that you can (at least potentially) write the dereference. But what you can't do is assign the access discriminant to most other access types, because the accessibility check will fail. It can only be assigned to some type that will live less long than the object with the access discriminant (which usually will be *very* short-lived). If you don't need (visible) dereferences at all, you should definitely use a handle type like the Cursor type of Ada Containers. Indeed, I think that the vast majority of the time, you should simply use the Cursor type directly (putting the objects into appropriate instances of the containers). There you don't have any visible access types (and any existence of them is easily detected with tools, see below). As for the concern about using Unchecked_Deallocation on a local access type: it's always bad practice to deallocate something for a type other than the one it was allocated for. And, sure, the compiler can't detect this. But this is just one out of dozens of ways that a malicious programmer could damage your application. There is no way that Ada could possibly prevent them all without becoming far too restrictive to be able to accomplish anything. (Example: SPARK.) There is always an important role to play for the culture and/or management of an organization. Both the culture and rules (enforced with external tools like AdaControl) should minimize the possibility of rouge programmers. But no one can prevent intentional maliciousness; at best you can only minimize it. It probably was a mistake to allow allocations for general access types (and by definition, if there were no allocations, there could be no DEallocations). [It is best is allocations are done for a pool-specific type and converted to the general access type as needed.] But it's way too late to change that now, it surely would break many existing Ada 95 programs. > It would seem that if everyone is in agreement that doing >something is bad practice and should be avoided the language ought to >have a way to prevent it, but I suppose when you start in with >Unchecked_Anything, the results are by definition unpredictable. Exactly. >If I were king of Ada, i would just cut through the tricks and add a >new 'reference' type; basically just syntactical sugar for a constant, >not null, auto-dereferenced, optionally limited access type. It would >cut down on errors, simplify the syntax, and even present room for >compile-time optimizations. It's strange to me that a language of >such a high level of abstraction when it comes to everything else >still regards access types with the underlying 'address stored in >memory' mentality. We looked at the possibility for Ada 2012, but adding a new kind of access type that was "just a little bit different" than the existing ones did not look very appealing. Part of the problem is a completely new kind of type cannot do anything to make Ada simpler, because all of the old kinds of types are still there and still needed. (It's not like you can replace allocations with a "ref" type that doesn't support allocations, and allocations are still going to be needed.) [Also, the sort of type you define is essentially a standard private type -- we surely don't need a new language feature for that! It's only interesting if it has some access-like behavior.] Another problem is that a "limited" access type (another idea we looked at) would be something totally new: there are no elementary limited types in Ada today. (A limited private type completed with an elementary type is still considered composite.) For instance, an immutably limited type (which this probably would be) is always passed by reference, something we clearly don't want for a reference type. So we'd be looking at major surgury to the language, and no major benefit. Moreover, when we studied the needed accessibility rules, it turned out that they were essentially identical to the ones for access discriminants. Thus we decided to just add some "sugar" to make access discriminants usable, rather than adding a new type. Randy.