[rust-dev] No range integer type? Saftey beyond memory?

Graydon Hoare graydon at mozilla.com
Mon Apr 22 09:18:54 PDT 2013

On 21/04/2013 12:09 AM, tsam at tormail.org 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.



More information about the Rust-dev mailing list