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: g2news1.google.com!news4.google.com!feeder2.cambriumusenet.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!138.195.8.3.MISMATCH!news.ecp.fr!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, 2 May 2011 20:40:28 -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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1304386831 1697 69.95.181.76 (3 May 2011 01:40:31 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 3 May 2011 01:40:31 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-RFC2646: Format=Flowed; Original Xref: g2news1.google.com comp.lang.ada:19129 Date: 2011-05-02T20:40:28-05:00 List-Id: "Florian Weimer" wrote in message news:87d3k2u36e.fsf@mid.deneb.enyo.de... >* Randy Brukardt: >> "Florian Weimer" wrote in message >> news:87tydfbtp3.fsf@mid.deneb.enyo.de... >> ... >>> And once there is something like this in the language, it is difficult >>> to decide if a new addition (such as aliased parameters) make things >>> worse or not. >> >> Not sure how something that adds new capabilities only for >> elementary types could make anything worse. > > It introduces a new form of aliasing. This will be problematic, I > fear. In particular, extreme care is necessary so that the cop-out in > 3.7.2(4) is still the only one which is needed. With this rule (I > don't know if this is the current text): > > | If the formal parameter is an explicitly aliased parameter, the type > | of the actual parameter shall be tagged or the actual parameter > | shall be an aliased view of an object. > > it is possible to obtain an aliased view of a discriminant-dependent > record component of tagged type which is not delimited by a subprogram > call. But this is not a new capability. All tagged type parameters are implicitly aliased already in Ada (Ada 95 specifically), so there is nothing new being added here. (And in all honesty, all tagged objects should be implicitly aliased; it is a mistake to require that declaration on tagged types.) > This would allow to write the Conversion function like this: > > function Conversion (S : Source) return Target is > type Source_Wrapper is tagged record > S : Source; > end record; > type Target_Wrapper is tagged record > T : Target; > end record; > > type Selector is (Source_Field, Target_Field); > type Magic (Sel : Selector := Target_Field) is record > case Sel is > when Source_Field => > S : Source_Wrapper; > when Target_Field => > T : Target_Wrapper; > end case; > end record; > > M : Magic; > > function Convert > (T : aliased Target_Wrapper) > return access constant Target > is > begin > return T.T'Access; > end Convert; > > T : Target renames Convert (M.T).all; > > begin > M := (Sel => Source_Field, S => (S => S)); > return T; > end Conversion; > > (I haven't checked with an Ada 2012 compiler, so this is somewhat > speculative.) 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). You could probably do it by adding an additional level of subprogram calls (that is, by passing T.T to another function that returns the access value). But I think you can already do that in Ada 95 (perhaps you would have to use 'Unchecked_Access there). 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]. 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 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. It's not a real problem in practice because the use of constrained discriminated types is pretty rare. 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. > 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). >> Cases like this is why I like to say that all real Ada programs are >> erroneous, so any result is allowed. :-) > > It's a bit disappointing because all those nitty-gritty rules intended > to ensure type safety which make the language quite complicated, and > there's still such a hole. It's certainly at odds with the marketing > materials. Type safety is not about detering malicious programmers, merely careless ones. And what you are doing is clearly malicious, since its intent is to hide an Unchecked_Conversion operation in some other, far more complex form. Unless this is likely to happen by accident (and it is not), there isn't really a problem. We actually considered repealing that 3.7.2(4) for Ada 2012, but decided not to simply because it would be very hard on programmers (you could never trust a composite constraint). Programmers *want* to trust constraints, even though they aren't anywhere near as meaningful as most think. (We had a replay of this with the predicate feature; there we decided to separate the "meaningful" ones from the other kind.) Randy.