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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.238.7 with SMTP id vg7mr11135985vec.22.1402243991579; Sun, 08 Jun 2014 09:13:11 -0700 (PDT) X-Received: by 10.182.22.97 with SMTP id c1mr126822obf.4.1402243991410; Sun, 08 Jun 2014 09:13:11 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.mb-net.net!open-news-network.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!hw13no5570954qab.0!news-out.google.com!qf4ni19596igc.0!nntp.google.com!h3no125215igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 8 Jun 2014 09:13:11 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=71.252.147.203; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 71.252.147.203 References: <3bf7907b-2265-4314-a693-74792df531d1@googlegroups.com> <51e9fd4f-e676-4d2f-9e21-1c782d71092e@googlegroups.com> <5391ffa4$0$6611$9b4e6d93@newsspool4.arcor-online.net> <53942fa4$0$6670$9b4e6d93@newsspool3.arcor-online.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <234602fb-4571-4b4d-b16c-7a4984511fe4@googlegroups.com> Subject: Re: a new language, designed for safety ! From: "Dan'l Miller" Injection-Date: Sun, 08 Jun 2014 16:13:11 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4375 X-Received-Body-CRC: 2768814589 Xref: news.eternal-september.org comp.lang.ada:20181 Date: 2014-06-08T09:13:11-07:00 List-Id: On Sunday, June 8, 2014 8:56:56 AM UTC-5, Robert A Duff wrote: > Georg Bauhaus writes: > > - "I can view this Obj as of type TA and call Op" > > (Ada, wrong view) > > > > - "I can send Op: to Obj of presumed type TA" > > (Objective-C, no method) >=20 > The two errors seem rather different, to me. To get the Ada error, you > have to do a downward type conversion, something that is well known to > be questionable -- you need to be careful to say "if X in T3'Class...". They seem quite different to me too. ASIS could search for all downward-ca= st syntax and flag it. One of the very few areas where C++98 and later is = superior to even Ada2012 is that the permissible downcast syntaxes are obno= xiously obvious in modern C++ to facilitate easier pattern-matching via gre= p and its brethren: 1) dynamic_cast< Type2 >( expressionOfType1 ), which uses runtime-type-iden= tification (RTTI) to perform an Ada-like runtime check 2) static_cast< Type2 >( expressionOfType1 ), which is an unsafe* compile-t= ime forcing of Type2's virtual-function table instead of Type1's. If Type2= does not conform to Type1 in this regard (e.g., unimplemented member-funct= ion), then undefined* behavior occurs (e.g., eventual crash, corruption of = resources, potential attack surface for a worm to inject machine code). Unfortunately, Ada's downcast syntax is not so obnoxiously conspicuous to t= he human eye or to mere regular-expression-only pattern-matchers. To rigor= ously search for Ada downcasts throughout all source code, it seems that a = parser with the expressive power of ASIS is needed. * "Unsafe" here is defined using Mr. Duff's narrower definition of "undefin= ed behavior" in an unsafe language, as established on another recent thread= -branch above back along this thread. Of course, undefined behavior in an = "unsafe language" also meets my wider definition of "unsafe system" since 1= ) the compiler plus source code that it is compiling forms a system and 2) = undefined behavior could easily be the root-cause bodily injury or death. > The dangling dispatch error in Objective C can happen on any call, > and there's no practical way to protect against it. i.e., no practical way *within* Objective-C, the way that Objective-C is = defined today. Even with an Objective-C equivalent of ASIS (if one were ev= er to exist, such as based on LLVM-Clang's relatively lucid C++ compiler so= urce-code), there exist more avenues of precipitating a run-time error at t= ime of "sending" a "message" to an object in Objective-C than only downcast= ing. Hence, there is no especially-dangerous syntax to look for in Objecti= ve-C, because every single "message" "sent" to an object can be dangerous i= n the way that (only) downcasting is dangerous in Ada.