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,3a7c118fd2cc64f9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!kanaga.switch.ch!news-zh.switch.ch!switch.ch!news.belwue.de!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: A hole in Ada type safety Date: Sat, 07 May 2011 11:09:44 +0200 Message-ID: <877ha2op0n.fsf@mid.deneb.enyo.de> References: <87oc3odtci.fsf@mid.deneb.enyo.de> <87tydfbtp3.fsf@mid.deneb.enyo.de> <87d3k2u36e.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ruchba.enyo.de 1304759385 8822 172.17.135.6 (7 May 2011 09:09:45 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:KoeJMjwkMOyGNcMLVysPqshZnVo= Xref: g2news2.google.com comp.lang.ada:20153 Date: 2011-05-07T11:09:44+02:00 List-Id: * Randy Brukardt: > Actually, I think T.T'Access is illegal, because the component T is not > declared as aliased. You can take 'Access of the parameter T, but not of > some random component (as is currently the case in Ada). Wouldn't it work if the component T was aliased? > But this looks like an attempt to shot yourself in the foot; it's hardly > likely to happen by accident. Remember that no programming language can > really defend against malicious programmers; the point is to defend against > sloppy or careless programmers [which is all of us, sooner or later]. My first answer that was rather confrontational. Let me just say that this is the line of argument used by C advocates. > For instance, the tampering checks of the Ada containers implicit in > the new Reference routines can be defeated by the use of > Unchecked_Deallocation on the return object. But this is not > something that is reasonably going to happen by accident, and it is > out in the open for program reviewers (both tools and humans) to > find. It's not worth worrying about. It's true that use-after-free errors typically result in exactly the same type safety violation. But they seem to be rather hard to spot in COTS software, and I'm not sure that the programming languages are to blame. Manual memory management is just hard. >> It seems to me that you need a C++-like rule that accessing an object >> through a view which is not compatible with its dynamic type is >> erroneous. And this would be quite a defeat. > > But that's exactly what 3.7.2(4) is. And it has been in Ada since the > beginning. 3.7.2(4) has very precise syntact requirements ("a name denoting a subcomponent that depends on discriminants" etc.). I don't think it covers the new possibilities introduced by aliased parameters. > Also note that a lot of renaming and 'Access of discriminant-dependent > components is not allowed; we've tighened those rules with each version of > Ada. It's not clear to me if these rules are valuable when its easy to circumvent them. They mostly seem to increase the complexity of the language. >> The difficulty I alluded lies in the answer to this question: Are >> aliased parameters at fault, or are discriminants with defaults to >> blame? > > Almost certainly discriminants with defaults, since the problem has > existed in Ada since Ada 83, and we are not making it any worse > (that would be impossible, IMHO). I tend to agree. Would it make sense to deprecate discriminants with defaults? As a replacement, smart pointers could be added to the language, with syntactical overhead compared to access types, which would allow programmers to replace discriminants with default with a smart pointer to an unconstrained type. Implementations would be allowed to use reference counting, or full garbage collection. However, they would have to ensure that references to the object held by the smart pointer would remain live for the time any reference to it or its components exists (an actual subprogram parameter, for instance). There would be no promise that cycles do not result in memory leaks. Run-time complexity for reference counting is less than for full garbage collection. Making it a language feature, rather than a library-provided functionality, makes it easier for implementations to optimize updating the counts. As usual, there is a trade-off between flexibility and overhead: if the reference counters are kept separate, it is possible to implement weak pointers and safe references to sub-components. Intrusive counts provide better cache locality and the smart pointers themselves can be a single machine word. > Type safety is not about detering malicious programmers, merely careless > ones. I think type safety is important for ending up with language semantics that can be explained.