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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Rust's temporal safety for Ada/SPARK Date: Mon, 15 May 2017 18:19:43 -0500 Organization: JSA Research & Innovation Message-ID: References: <1c0e2c7c-4fd6-43d1-9848-f03e1a72bcb3@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494890384 20433 24.196.82.226 (15 May 2017 23:19:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 15 May 2017 23:19:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:46795 Date: 2017-05-15T18:19:43-05:00 List-Id: "Jeffrey R. Carter" wrote in message news:ofa4dh$15p$1@dont-email.me... > On 05/14/2017 06:46 PM, digitalkevlar@gmail.com wrote: >> >> So, can someone today use Ada in a straight-forward way to write single- >> or >> multi-threaded applications that are, in every use-case, totally immune >> at >> compile-time to use-after-free and double-free errors with zero, runtime >> overhead? Or can it not do that? > > Of course this is possible. It's very rare for well designed Ada to need > access types. An overwhelming majority of applications can be implemented > without ever writing "access". I would suggest that Jeff's answer here should be read to say that "well-designed Ada code has no need for dynamic checks". Ada has plenty of unsafe constructs (for low-level memory managment, machine access, and the like), but one never has to use them. Ada after all is about combining safety with capability -- we try to allow everything (including unsafe stuff), but try to make it clear what is unsafe so that code review tools can determine what issues exist. In any case, Ada code can be written so that there are no dereference checks and no dangling pointers. You obviously lose some capability when one does so. Does that matter? Depends on what you are doing. Static rules (of any sort) are always going to reduce capability, *especially* when it comes to multithreaded programs. I find it highly unlikely that any sort of static rules would actually work in "every use-case". That's been claimed many times in the past, and it has always turned out that the claims were *way* overblown. The people making such claims often don't understand multithreading well enough. (It's an area, like random numbers and probability, that a little knowledge is more dangerous than no knowledge.) I'm also very suspicious of any claims of new static rules simply because OOP pretty much forces dynamic checks if one uses references; strong typing breaks down for that and everything essentially becomes dynamic. There probably aren't any dereference checks, but you end up with dynamic type checks instead (substantially worse). Best thing is to avoid references altogether (but of course that too reduces capability). Randy.