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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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 Received: by 10.68.222.71 with SMTP id qk7mr12462946pbc.1.1328573768070; Mon, 06 Feb 2012 16:16:08 -0800 (PST) Path: lh20ni268556pbb.0!nntp.google.com!news2.google.com!postnews.google.com!z31g2000vbt.googlegroups.com!not-for-mail From: Simon Belmont Newsgroups: comp.lang.ada Subject: Re: Preventing Unchecked_Deallocation? Date: Mon, 6 Feb 2012 16:14:44 -0800 (PST) Organization: http://groups.google.com Message-ID: <26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com> References: <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.googlegroups.com> <4350713b-6ac3-4b22-b221-8da2bac52fea@t5g2000yqk.googlegroups.com> NNTP-Posting-Host: 24.218.138.255 Mime-Version: 1.0 X-Trace: posting.google.com 1328573767 20659 127.0.0.1 (7 Feb 2012 00:16:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 7 Feb 2012 00:16:07 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z31g2000vbt.googlegroups.com; posting-host=24.218.138.255; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.2),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-06T16:14:44-08:00 List-Id: On Feb 6, 11:21=A0am, Adam Beneschan wrote: > On Feb 5, 8:42=A0am, Simon Belmont wrote: > > > On Feb 4, 9:40=A0am, AdaMagica wrote: > > > > Don't understand your problem. However, keep in mind that UD with a > > > type different from the one with which the objects were allocated is > > > erroneous. > > > When you say erroneous, do you mean forbidden by the language (i.e. an > > exception) or that it will cause undefined operation? =A0My concern is > > that if a unit exposes an access value to other units, any of them may > > use UD to delete the object at any time. =A0Obviously this sort of > > behavior would cause the program to quickly crash due to a null > > pointer, but all things being equal I would prefer a compile-time > > mechanism to prevent the UD outright. > > I think the solution is not to expose the access type, but have your > package define a private type. =A0Ada 2012 is supposed to have new > mechanisms that allow packages to define "dereference" operations that > could allow package users to use the same kind of syntax on objects of > private types that they can use on access types. =A0If you do this, then > it's likely that the package that defines the type can control what > operations are available and not make Unchecked_Deallocation > available. =A0However, I haven't yet studied the new feature so I can't > say for sure. > > As a general rule, though, I believe that if a package does make an > access type visible, users of the package should not try to deallocate > any objects of the type themselves, when objects of the type are > supplied by the package. =A0Instead, the package should provide > operations to do any needed deallocations (ideally not a "Deallocate" > operation, but perhaps a "No Longer Needed" operation so that it's the > package that defines the type that decides when it's OK to > deallocate). =A0I don't think the language can prevent package users > from deallocating, except by using private types. =A0But I'd say that > doing your own Unchecked_Deallocation on an object allocated by > another package (if the documentation doesn't explicitly say it's OK) > is just poor programming, and there's a limit to how much Ada can do > to prevent poor programmers using Unchecked routines from doing > damage. =A0(Even if you used private types, Ada can't prevent a user > from using Unchecked_Conversion to convert to an access type and then > deallocating it. =A0And I think I've known some programmers who wouldn't > see anything wrong with doing that, if they believed it would solve > their problem.) > > Conceivably, it might be possible to add a "not deallocatable" aspect > to an access type and add language rules to Unchecked_Deallocation and > to the rules on type conversions so that this could be prevent. > However, since the language seems to have been moving in the direction > of making it simpler not to have visible access types at all, I doubt > that ARG would deem worthwhile to add this kind of feature. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Adam I agree with all your points, and was essentially looking for a way to enforce this at compile time. 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. 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. 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. Thank you again -sb