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 Received: by 10.68.226.10 with SMTP id ro10mr11641398pbc.6.1328548959762; Mon, 06 Feb 2012 09:22:39 -0800 (PST) Path: lh20ni267501pbb.0!nntp.google.com!news1.google.com!postnews.google.com!t5g2000yqk.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Preventing Unchecked_Deallocation? Date: Mon, 6 Feb 2012 08:21:24 -0800 (PST) Organization: http://groups.google.com Message-ID: <4350713b-6ac3-4b22-b221-8da2bac52fea@t5g2000yqk.googlegroups.com> References: <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 X-Trace: posting.google.com 1328548959 19733 127.0.0.1 (6 Feb 2012 17:22:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 6 Feb 2012 17:22:39 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: t5g2000yqk.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ 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; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-02-06T08:21:24-08:00 List-Id: 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. Ada 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. If 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. However, 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. Instead, 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). I don't think the language can prevent package users from deallocating, except by using private types. But 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. (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. And 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. -- Adam