FWIW I'd *love* if all integer types could get efficient dynamic range checking turned on in Debug builds. So it wouldn't be a safety issue in the traditional sense because it would be disabled in shipping builds, but it would be great for catching bugs. Still needs to be efficient because Debug builds that aren't interactive don't get used for development.
On Mon, Apr 22, 2013 at 9:18 AM, Graydon Hoare <[email protected]> wrote: > On 21/04/2013 12:09 AM, [email protected] wrote: > > I worry that once Rust fixes memory safety it will quickly be >> time to replace Rust to correct all the other programmer-traps. >> > > Yeah. There are unfortunately always limits and compromises when making a > real language. Rust is attacking a very difficult niche so we have to spend > a lot of energy on things that are not strictly about safety. But I > appreciate your concern. > > > In Rust (like C) there doesn't appear to be any way to access the >> processor flags to cheaply detect overflow on machine types >> > > It would be done with some per-platform inline asm (which we support now), > or intrinsics, or an attribute on (say) newtyped integral types. Any of > these would probably be ok. The attribute form would make it part of the > type, so you'd wind up with checks performed on cast boundaries as well as > any non-approximated operations. > > > your "safe integer objects" will likely have poor performance and of >> course not work with the standard libraries. >> > > I believe any such integration -- inline asm, intrinsics or attribute -- > would be similar, performance-wise. Maybe LLVM's scheduler could do a > better job with them if it knows more about the instruction (an argument > for intrinsics), and if it knows about the type range itself it may > eliminate certain branches as dead code, but otherwise inlining should boil > off most of the abstractions equivalently. > > > Integrated ranged types would >> also be synergistic with memory safety since a function which takes >> limited-range inputs can sometimes be statically proven memory-safe when >> it couldn't otherwise be, allowing the boundary check to be hoisted out of >> functions entirely even across closed-source-library boundaries when their >> interfaces are range constrained. >> > > Not entirely. There are always limited approximations at work in these > things; range checks can only be statically eliminated in some cases when > the approximation is tight, otherwise it has to be repeated on each > potentially range-violating arithmetic operation. > > LLVM does expose range-limited types and, presumably, does some such > check-elimination. I'd not be opposed to absorbing this via a > well-integrated attribute on integer types. > > We've also had some requests for a mechanism to enable overflow checking > on _all_ integer types within a given static or dynamic program extent, > using attributes. And similar things are going to be desirable wrt. the > floating point environment, which is trickier since it's latent in the CPU > state rather than the (static) operations performed. Again, I'd be happy to > work through developing patches for this and exploring the problem space. > It's a set of bugs usually swept under the rug in C. > > > Overflow is something that ada seems to handle well, but ada doesn't >> really seem to be in the running for a wide spread next language outside >> of certain niches. >> > > Agreed. > > -Graydon > > > ______________________________**_________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev> > -- Sebastian Sylvan
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
