On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay <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. > > > 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.") > 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 Mill CPU architecture handles overflow nicely and promises much > > higher performance, like extending DSP abilities into ordinary software > > loops like strncpy(). Whether this one takes off or not is hard to say. > > That little company could use a big partner. > > It has to exist before it can succeed or fail. > > Yea. -- Jerry
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
