From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!weretis.net!feeder8.news.weretis.net!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Unchecked_Deallocation with tagged types Date: Tue, 20 Apr 2021 13:53:29 -0500 Organization: JSA Research & Innovation Message-ID: References: <607b56f8$0$3721$426a34cc@news.free.fr> <07863309-4541-4497-8cec-d88179e634bdn@googlegroups.com> <3d6e49b6-f195-4dc2-bf4b-795f18f2da9dn@googlegroups.com> Injection-Date: Tue, 20 Apr 2021 18:53:30 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="12547"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: reader02.eternal-september.org comp.lang.ada:61868 List-Id: Only if you enforced a Restriction (No_Unchecked_Deallocation_Instances)! Otherwise, you have two mechanisms to do the same thing, which is even less easy to track. And of course, you couldn't usefully do that in existing Ada code (of which there is a lot). 'Free makes more sense in a new language (an Ada follow-on). OTOH, an Ada follow-on would most likely have access types with automatic deallocation as proposed by Tucker in one of the many AIs on ownership. So using any form of explicit deallocation would be discouraged (as would the use of raw pointer types). Randy. "Gautier write-only address" wrote in message news:3d6e49b6-f195-4dc2-bf4b-795f18f2da9dn@googlegroups.com... Le dimanche 18 avril 2021 à 17:14:13 UTC+2, J-P. Rosen a écrit : > I meant it the other way round: if the module has no "with > unchecked_deallocation", you know it does not deallocate anything, > without looking at the entire body. Not at all: the instantiation can be defined of in another package - and it is often the case - with any name (Free, Dispose, ...). So actually with the present way it is difficult to track where unchecked deallocation is used, plus it is tedious for the programmers. The P'Free atttribute or the "unchecked_free P;" statement would be straightforward to track.