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!weretis.net!feeder4.news.weretis.net!newsfeed.straub-nv.de!nuzba.szn.dk!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: A hole in Ada type safety Date: Mon, 9 May 2011 15:41:45 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <87oc3odtci.fsf@mid.deneb.enyo.de><87tydfbtp3.fsf@mid.deneb.enyo.de> <87d3k2u36e.fsf@mid.deneb.enyo.de> <877ha2op0n.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1304973707 27932 69.95.181.76 (9 May 2011 20:41:47 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 9 May 2011 20:41:47 +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.5931 Xref: g2news2.google.com comp.lang.ada:20172 Date: 2011-05-09T15:41:45-05:00 List-Id: "Florian Weimer" wrote in message news:877ha2op0n.fsf@mid.deneb.enyo.de... >* 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? Maybe, but there are fairly strong rules on which components can have 'Access taken when they are discriminant dependent. (Note that these rules are not about aliasing, but rather to detect cases where components disappear because of direct modification. But of course they prevent a lot of aliasing problems as well.) ... >> 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. How so? C makes no attempt to detect problems caused by sloppy or careless programmers. It says that you shouldn't be sloppy or careless. Ada says that we'll detect errors caused by sloppiness or carelessness, but not by maliciousness (as that was thought to make the language unusable). Just to give an example unrelated to the topic of discussion, you can use Unchecked_Conversion to break privacy - just dupication the full type declaration from the private part into your own code and Unchecked_Convert to/from the original private type to your full declaration. This clearly does all kinds of violence to the typing model, but it is not going to happen by accident. So Ada allows Unchecked_Conversion even though it can do untold damage if abused. >> 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. I think you are missing the point. If you do something abusive in the code, you can circumvent the checks. But that doesn't happen by accident. Also note that the problem I was referring to has nothing to do with use-after-free; the problem is that the Unchecked_Deallocation triggers an early finalization while you still can be holding a valid copy of the wrapped access value. >>> 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. Sorry, but there aren't any new possibilities, unless we all have missed something very fundemental. Ada has always allowed composite parameters to be passed by reference, and most compilers in fact do that. You can take 'Unchecked_Access of components of any parameters that you want. You probably can't take 'Access of those components (the accessibility is local). Aliased parameters have very little effect on this situation. The accessibility is changed very slightly so that it can be returned as part of a return object, but only in cases that already have very short lifetimes (mostly access discriminants and anonymous access returns). The parameter is guaranteed to have the same lifetime as the return object. So in virtually all cases, you'll still need to use 'Unchecked_Access to get access to components. The problem here is parameter aliasing, and that was a problem with programming languages long before Ada was designed. Ada didn't try to solve it, and it's now 30 years too late to do so. >> 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. Ada has never made any attempt to prevent malicious programmers; to do so would require having no low-level features in the language. The problem here (if there is a problem) is that this might happen by accident. But there is no more likelyhood of that now than in Ada 83 (and I'd argue it is a lot safer now, rather than using untyped 'Address to access components). >>> 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? I don't think so, it is much too fundemental of a feature. Note that the problem here is really parameter aliasing -- any time that a parameter can be accessed both by the parameter name and put some other name there is possibly trouble. (At least, you have a dependence on the parameter passing implementation, which Ada doesn't specify for many kinds of types.) Note that there are potentially problems for *any* kind of type -- this is precisely why Ada requires by-copy parameter passing for elementary types. It's not limited to discriminants with defaults. Ada 2012 has added some attributes which can be used to test if this is happening (of course, that requires knowing that there is a potential problem). Beyond that, it is relatively easy for tools that have the entire source code available to check for such things -- but it isn't a problem that the language (which has to allow compilation of partial programs) can fix. > ... 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. Tucker tried to propose something like this (see AI05-0111-1). The feedback that we got (especially from the Ada conferences) was that it is just too complex to use. The complaint is that if you are going to work that hard, you probably would just as soon use real garbage collection. Instead, we decided to address the two things that users can't write themselves -- control over finalization of allocated objects, and convinient syntax for user-defined pointers. Thus Ada 2012 adds subpools and the Reference aspect, and nothing else. We hope that if smart pointers are really a good idea, that users and implementers will create implementations using these building blocks. And then we can consider standardizing something in Ada 2020 if they are being used a lot. It doesn't make much sense to standardize something that few people appear to be interested in (even if it might be a good idea in a vacuum). Randy.