[rust-dev] Integer overflow, round -2147483648

Benjamin Striegel ben.striegel at gmail.com
Sat Jun 21 16:55:31 PDT 2014

> No one will use Rust if it's slow. If it uses checked arithmetic, it
> will be slow. There's nothing subjective about that.

This is the only argument that matters.

If we are slower than C++, Rust will not replace C++ and will have failed
at its goal of making the world a safer place. The world already has a glut
of safe and slow languages; if inefficiency were acceptable, then C++ would
have been replaced long ago.

In addition, bringing up hypothetical CPU architectures with support for
checked arithmetic is not relevant. Rust is a language designed for 2014,
not for 2024.

And if in 2024 we are all suddenly gifted with CPUs where checked
arithmetic is literally free and if this somehow causes Rust to be
"obsolete" (which seems unlikely in any case), then so be it. Rust is not
the last systems programming language that will ever be written.

On Sat, Jun 21, 2014 at 7:07 PM, Daniel Micay <danielmicay at 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.
> > 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.
> > 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.
> > 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.
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/e1ce95ad/attachment.html>

More information about the Rust-dev mailing list