Apologies for adding heat to the discussion. The industry needs to make progress on security/safety-critical systems, and Rust does a great deal for that by bringing memory safety to a C/C++ alternative.
This post about hardware traps for integer overflow <http://blog.regehr.org/archives/1154> is useful, even besides the issue of the full cost of traps. The post and its discussion explore alternatives. It links to this conference article about Understanding Integer Overflow in C/C++ <http://www.cs.utah.edu/~regehr/papers/overflow12.pdf>, which studied overflow bugs, vulnerabilities, and some overflow-checking techniques. One technique averaged 44% cost, ranging 0 to 191%. Another averaged 30%, ranging 0 - 95%. They discovered that "intentional uses of wraparound behaviors are more common than expected" but hard to find. The post also links to Wikipedia on Intel MPX <http://en.wikipedia.org/wiki/Intel_MPX>: Intel is adding x86 extensions to aid memory safety! I think it's for array bounds checking, but the article is unclear. If the choice is a Rust with inconvenient and often unused overflow safety that kills off C/C++ vs. a Rust with overflow safety that doesn't, I vote for the former. The open design questions are ergonomics of checked and wraparound arithmetic. It'd be great if uses of wraparound arithmetic were explicit. On Sun, Jun 22, 2014 at 2:05 PM, Daniel Micay <danielmi...@gmail.com> wrote: > A `Vec<u32>` and `Vec<uw32>` would be entirely distinct types. ... > THAT is a knockout blow for the distinct-types design for wrapping integers. (BTW is there a use for *signed* wraparound?) On Sun, Jun 22, 2014 at 2:09 PM, Rick Richardson <rick.richard...@gmail.com> wrote: > ... I would assume that one would really only care about checked math > during testing and dev. > Alas, that doesn't block security exploits. On Sun, Jun 22, 2014 at 2:26 PM, Daniel Micay <danielmi...@gmail.com> wrote: > Rust's design is based on the assumption that performance cannot be > achieved simply by having highly optimized inner loops. It takes a whole > program approach to performance by exposing references as first-class > values and enforcing safety via type-checked lifetimes. > > You can write an efficient low-level loop in Haskell or Swift, but you > can't build high level safe abstractions without paying a runtime cost. > > If someone isn't interested in this approach, then I have a hard time > understanding why they would be using Rust. > To move a lot of code from C/C++ to a place that has memory safety and less error-prone 1970's technology with 1960's macro processing and linking. For real-time programs, which need predictable response times whether or not they need high performance (often fixable with faster hardware). Many of these are embedded devices with small memory. Maybe Swift will work there but (1) it'll have to go beyond Apple hardware and OSs, and (2) reference counting has unpredictable delays when freeing a large network of objects. On Sun, Jun 22, 2014 at 2:23 PM, Daniel Micay <danielmi...@gmail.com> wrote: > The set of design compromises made by the language is ill-suited to a > use case where performance isn't critical. Is there a web page that lays out Rust's goals, design trade-offs, and intended uses? On Sun, Jun 22, 2014 at 2:12 PM, Cameron Zwarich <zwar...@mozilla.com> wrote: > Languages like Ada (and Swift, to a lesser extent), allow for slightly > imprecise exceptions in the case of integer overflow. ... the “As > Infinitely Ranged” model ... > > I know that some people don’t want to require new compiler techniques (or > are afraid of relying on something outside of the scope of what LLVM can > handle today) > >From TFA: > AIR integers do not require precise traps and consequently do not break or > inhibit most existing optimizations. Hopefully Apple will contribute its Swift compiler to the LLVM source tree. That includes overflow detection. Also if needed, they have the ability to customize their ARM chips and some sway with Intel. On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay <danielmi...@gmail.com> wrote: > If we had compiler switches for ... I think even 2 dialects is too much... > Yes. When one C dialect calls another via dynamic loading, bad things happen, and there's no debugger on the robot. (Speaking from experience.) -- Jerry
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
