comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Rust's temporal safety for Ada/SPARK
Date: Mon, 15 May 2017 18:19:43 -0500
Date: 2017-05-15T18:19:43-05:00	[thread overview]
Message-ID: <ofdd2f$juh$1@franka.jacob-sparre.dk> (raw)
In-Reply-To: ofa4dh$15p$1@dont-email.me

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> 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.


  parent reply	other threads:[~2017-05-15 23:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-13 20:33 Rust's temporal safety for Ada/SPARK digitalkevlar
2017-05-13 21:19 ` Jeffrey R. Carter
2017-05-14 10:19   ` Niklas Holsti
2017-05-15 19:07   ` Simon Wright
2017-05-15 19:30     ` Jeffrey R. Carter
2017-05-17 21:21     ` moy
2017-05-14  3:24 ` Robert Eachus
2017-05-14 16:46 ` digitalkevlar
2017-05-14 17:18   ` Dmitry A. Kazakov
2017-05-14 17:36   ` Jeffrey R. Carter
2017-05-14 19:59     ` Niklas Holsti
2017-05-14 20:43       ` Simon Wright
2017-05-15  7:27         ` Dmitry A. Kazakov
2017-05-14 22:20       ` Dennis Lee Bieber
2017-05-15 16:23       ` Jeffrey R. Carter
2017-05-15 23:19     ` Randy Brukardt [this message]
2017-05-16 16:45       ` Shark8
2017-05-16 21:36         ` Randy Brukardt
2017-05-16 23:37           ` Shark8
2017-05-14 21:28 ` moy
2017-05-15 22:59 ` digitalkevlar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox