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,29d8139471e3f53e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news2.google.com!postnews.google.com!s19g2000vbr.googlegroups.com!not-for-mail From: Cyrille Newsgroups: comp.lang.ada Subject: Re: Preventing type extensions Date: Fri, 24 Sep 2010 02:27:53 -0700 (PDT) Organization: http://groups.google.com Message-ID: <37ae2382-9f7d-4790-be5f-e380b9220d75@s19g2000vbr.googlegroups.com> References: <87iq2bfenl.fsf@mid.deneb.enyo.de> <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net> <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net> <8f6cceFrv2U1@mid.individual.net> <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com> <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com> <5c0d7798-ba09-4bd0-a28f-f1b028cce927@y3g2000vbm.googlegroups.com> <9df21c09-f611-4088-811c-c092452adffc@e20g2000vbn.googlegroups.com> NNTP-Posting-Host: 212.99.106.125 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1285320473 7994 127.0.0.1 (24 Sep 2010 09:27:53 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 24 Sep 2010 09:27:53 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s19g2000vbr.googlegroups.com; posting-host=212.99.106.125; posting-account=bNhsVwoAAAB6XmNPWgYcbUm6npIwL2C4 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:14229 Date: 2010-09-24T02:27:53-07:00 List-Id: On Sep 24, 10:39=A0am, Cyrille wrote: > On Sep 24, 10:16=A0am, "J-P. Rosen" wrote: > > > and replace every redispatching call to M2 by a call to M2_Class, then > > the big case disappears. You need (of course) to check coverage for > > M2_Class, but M1 needs to be checked only for values of type T, not for > > descendants. That's what I meant when I said that coverage testing drop= s > > from N to 1 > > OK, I kind of supposed you had something like that in mind. Many years > ago, we proposed a similar idea in a few papers, See for instancehttp://w= ww.adacore.com/wp-content/uploads/2006/03/Certification_OO_Ad.... > Another one written by Franco G. is even mentioned in Chelinsky's FAA > study on OO (seehttp://www.tc.faa.gov/its/worldpac/techrpt/ar0717.pdf). > The study is worth reading by the way... We had more automatic > translation in mind at the time but the idea is the same. > doing this Sorry, I hit the send button inadvertently. I was going to say: Suggesting to do such a transformation manually at the source code level as you do is particularly dubious since it is in the category of program transformations whose only purpose is to circumvent specific verifications. There are many such transformations that have been proposed to make MC/DC coverage easier... some would say to cheat on MC/DC... and, not surprisingly, it is not very well perceived by cert authorities. Anyway, DO-178C doesn't impose "pessimistic testing" as the only way to to verify safety of dispatching calls. It allows you to treat dispatching calls as normal calls as long as you can show separately that you have "local type consistency" (read LSP) for the types involved in dispatching calls. This additional verification can be done formally or using specifically designed tests such as verifying that all the functional tests attached to a class also work when the objects of this class involved in the testing are substituted by objects of the subclass. If your class hierarchy hasn't been designed to respect LSP (or if you are in a situation where you need to express properties that don't fit well with LSP, such as the example Dmitry gave earlier) then you have to go the pessimistic testing road. Why? because if you don't, there is a real risk that a non-conforming subclass method misbehave on a given dispatching call and standard coverage criteria doesn't guarantee that you have covered such case. If you want to use the "trick" you mention above, you better find a convincing reason at the design level for such a "peculiar" style because the transformation you suggest doesn't address the specific vulnerability that is supposed to be addressed by either pessimistic testing or the additional local type consitency verification. To conclude about differentiating T and T'Class, the trick you suggest here is easily implementable in other OO languages. There is nothing magic in creating a wrapper around a given dispatching call and use this wrapper at each dispatch point. The only problem is that it doesn't address the (perceived) vulnerability and thus doesn't meet properly the do-178c objective.