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=-0.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news2.google.com!goblin1!goblin.stu.neva.ru!news.astraweb.com!border5.a.newsrouter.astraweb.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!.POSTED!not-for-mail From: anon@att.net Newsgroups: comp.lang.ada Subject: Re: A hole in Ada type safety Date: Sat, 14 May 2011 23:47:52 +0000 (UTC) Organization: Aioe.org NNTP Server Message-ID: References: <87oc3odtci.fsf@mid.deneb.enyo.de> <87tydfbtp3.fsf@mid.deneb.enyo.de> Reply-To: anon@anon.org NNTP-Posting-Host: 6VTg3T40CaOAiJW9x1Sg9A.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: IBM NewsReader/2 2.0 Xref: g2news2.google.com comp.lang.ada:20249 Date: 2011-05-14T23:47:52+00:00 List-Id: AdaMagica: Some times a programmer may need a only a few checks suppressed instead of all checks as with the RM Unchecked_Conversion function. Then there's the idea of creating your own function just like some here will say create your own version of an Integer instead of using the one defined in the Standard package. Now, I have one simple designed Unchecked_Conversion function that work for any Ada 83 compiler, and a second version that works for any Ada 95 compiler for all types used in that version of the language. Include a "unconstrained discriminant limited private" type. Florian Weimer: My design converts all types and I did not need to use aliased or tag type to add the discriminant-dependent feature. Just play with it a little and you will see the answer. Note: One thing. Any and all Unchecked_Conversion function just like Machine_Code Insertions adds a safety risk to the party. Plus, the conversion functions are easier to hide in a large scale project. This all started because of an answer that "Robert Duff" gave about about AARM-3.7.2(4,4.a), which refers to AI83_00585 and "Erroneous Execution". In looking at that Ada Issue I see only a compiler design error not an "Erroneous Execution" error. The fix is for the compiler to add either two or three checks in the elaborate code depending how the compiler evaluate the equation, which means no "Erroneous Execution". But in 15 plus years GNAT has not correct this compiler identifiable error which makes me think how many more "Erroneous Execution" has GNAT and other Ada venders skip fixing making the language less secure. Also, I knew that Adam and Randy were just talk!!! Makes me think that they are waiting for someone to create an example of the "extended return statement" so, they can learn how to use it. Because in looking at the AIs for 95 and 2005 and the ACVC 3.0 there is no example of an "extended return statement" for any "unconstrained discriminant limited private" except for those that call a function. But that not always possible. In <87tydfbtp3.fsf@mid.deneb.enyo.de>, Florian Weimer writes: >* Robert A. Duff: > >> Florian Weimer writes: >> >>> I don't know if this is a new observation---I couldn't find >>> documentation for it. >> >> It's not new. It is documented in AARM-3.7.2(4,4.a), >> which dates back to Ada 83 days. > >Ah. I didn't realize that call to Convert was already erroneous. > >It does not seem possible to extend the restrictions on 'Access >prefixes to to subprogram parameters (due to the way controlled types >are implemented, for example). > >>> Our implementation lacks the full power of Ada.Unchecked_Conversion >>> because it does not supported limited or unconstrained types. However, >>> it is sufficient to break type safety. >> >> Yes. Anything that is erroneous necessarily breaks type safety. >> If you look up "erroneous execution" in the index, you'll find >> them all. > >My concern was that this was not explicitly labeled as erroneous. 8-) > >> Your comment, "This note shows that a combination of safe-looking >> language features can be used to undermine type safety, too." >> is the key point. It is indeed unfortunate when "safe-looking" >> features can be erroneous. > >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.