[rust-dev] No range integer type? Saftey beyond memory?
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