On 21/06/14 07:27 PM, Jerry Morrison wrote: > > On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay <danielmi...@gmail.com > <mailto:danielmi...@gmail.com>> wrote: > > On 21/06/14 06:54 PM, Jerry Morrison wrote: > > I agree with Vadim that the world will inevitably become > > security-conscious -- also safety-conscious. We will live to see it > > unless such a bug causes nuclear war or power grid meltdown. > > > > When the sea change happens, Rust will either be (A)/ the attractive > > choice for systems programming/ or (B) /obsolete/. Rust already > has the > > leading position in memory safety for systems programming, so it's > lined > > up to go. > > No one will use Rust if it's slow. If it uses checked arithmetic, it > will be slow. There's nothing subjective about that. > > > Surely there's a way to make the language and libraries ready for > overflow safety while able to perform without it in the short term.
I'm not sure what you mean by this. If one day ARM gets instructions for trapping on overflow, that's all well and good, but Rust can't use it to implement fail-on-overflow. If the proposal was based around aborting on overflow rather than failing, it would be able to use those instructions. > > The world desperately needs a C++ replacement for real-time, > > safety-critical software before that ever-more-complicated language > > causes big disasters. Rust is the only candidate around for that. (Or > > maybe D, if its real-time threads can avoid GC pauses.) CACM's recent > > /Mars Code/ article > > <http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext> shows > > the extremes that JPL has to do to program reliable space probes. > > Smaller companies writing automobile engine control systems > > > > <http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences> > > and such will soon be looking for a more cost effective approach. > > Trapping on overflow doesn't turn the overflow into a non-bug. It > prevents it from being exploited as a security vulnerability, but it > would bring down a safety critical system. > > > A safety critical system needs to catch and recover from thread > failures, e.g. by restarting it, or failing over, or gracefully shutting > down. The first requirement is to keep the problem from causing > collateral damage and opening exploitable holes. Systems like phone > switches written in Erlang are good at the recovery part. > > (And by "smaller companies" I meant "smaller, less funded teams.") Rust's task failure isn't very isolated or robust. A failure in a destructor called during failure will abort the process. A failure in a destructor when not already failing will not call the inner destructors as it would be memory unsafe. A failure also has to poison RWLock / Mutex so that all other threads with handles to the same shared data will fail too. I don't think these issues are going to be fixed, unwinding in a language with destructors is just inherently broken. I think process separation is a far better option for robust systems. > > Companies like Intel see so much existing C/C++ software getting by > > without overflow safety and conclude it doesn't matter. Let's not let > > their rear-view mirror thinking keep us stuck. Eventually > customers will > > demand better security whether there's a speed penalty or not. > > > > CPU designers could say they've given us so much instruction speed > that > > we can afford to spend some of it on overflow checking. Fair > point. When > > the software folks have demonstrated the broad need, Intel can > speed it > > up, whether by optimizing certain instruction sequences or adding new > > instructions. > > Overflow checking means a branch on every integer arithmetic operation. > > It means every arithmetic operation is impure (unwinding) so LLVM won't > be able to hoist stuff out of loops unless it proves that there's no > overflow, which is rare. For example, this prevents it from hoisting a > bounds check out of a loop by introducing a second kind of impure > failure condition. > > It also prevents auto-vectorization, which is increasingly important. A > language without good auto-vectorization is not going to be an > interesting systems language down the road. > > > How about propagating the overflow info downstream like a NaN by a > limited distance, rather than throwing an immediate exception? The hardware doesn't support this. Any kind of checked overflow means no auto-vectorization. You only get wrapping arithmetic and in some cases saturing arithmetic.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
