Guaranteeing memory safety in Rust [video]
air.mozilla.org
air.mozilla.org
~ How do you tie the ownership of [the element array] to the vector? How does the compiler know that when you take a reference into the element array, [it should treat the vector itself as borrowed]?
~ What happens if I write my own library class [instead of using one that's part of the standard library like vec]?
~ The overall discipline hasn't been too difficult to been follow.
~ Most of the issues we hit are issues in the implementation. (e.g. the precise way the borrow-checker checks inveriants, reasons about lifetimes and whatnot.) These kinds of issues are fixable, and we continue to improve them all the time.
~ I don't speak for the entire Servo team, but I feel like the discipline, the overall type-system strategy that Rust enforces, has been pretty friendly.
~ We still have a lot of unsafe code, but a lot of it is unavoidable, for calling C libraries. And also we're doing things like: we have Rust objects which are managed by the SpiderMonkey [JavaScript] garbage collector. Which is really cool that we can do that, but the interface has to be written in the unsafe dialect [of Rust].
One question that comes to my mind is that how Rust concurrency compares to Go concurrency. After this talk, and some little use of “goroutines”, Rust seems to be the choice of the wise, for it being seemingly more sage and still as easy to use as Go's. I'd love to read a reply from someone who knows concurrency/parallelism, who is most definitely not me.
Also, Rust does care a great deal about readability. You might scoff at this statement, but it's true: Rust's syntax works hard to strike a balance between all of clarity, consistency, regularity, readability, and familiarity. As the language gains wider use, understanding of these constraints improves; modern Rust has removed 95% of the sigils that characterized ancient Rust. There used to be tons of sigils, and many were largely inscrutable: ~, @, +, ++, -, more that I've forgotten. Now there's only two: & (for references, a sigil taken directly from C++) and * (for unsafe pointers, a sigil taken directly from C). And there are even some people who would like to see the * sigil for unsafe pointers go away.
Some of the Rust features can be disabled via compiler flags, on the other hand I rather pay a little bit for security.
Symbol mangling and exception handling can be disabled.
Split stacks are gone, but, at the moment, the prelude for checking stack bounds is still used to protect against stack overflow (I believe this can also be disabled).
In practice this is quite rare because of iterators, which do not need to do bounds checking. In the rare case in which you need to use indexes, you can always opt out of the safety without the use of a compile-time switch, exactly like the choice between C++'s "operator[]" and ".at()". The only difference is that the default is safe, and the unsafe version requires you to jump through the "unsafe{}" hoop, unlike C++.
Also, with MPX on Skylake even the bounds checking may well become zero-cost.
> symbol mangling
How does symbol mangling make your program go slower?
> exception handling frames
Also enabled by default in C++, and you can turn it off just as in C++. LLVM will also optimize it out if you don't use it and use LTO. On most architectures exception handling is zero-cost via table-driven unwinding (although it can inhibit optimizations).
> split-stacks (this may have changed?))
They're gone.
> this was and still is my complaint about it, the one way to fix it is death by a thousand knobs that modify functionality but by then it's not even the same language.
Nothing needs to be fixed, as none of the things you mention are an issue.
> Also the recent change adding -ffuntion-sections -fdata-sections (a hack imo) shows that the language or the implementation has an issue.
Why? Rust's compilation model is exactly the same as C++ "unity builds" (which are becoming the norm in large projects).
Preference in all honesty, what besides the obvious requires mangling?
> split-stacks
What took place of split stacks? guard pages?
> ffunction-sections fdata-sections
an example is to use weak aliasing of dummy functions - but this is sort of elf dependent (I have no idea how or if weak aliasing works in pe). I think this is an area that needs to be improved.
If I'm wrong, let me know.
> what besides the obvious requires mangling?
You can explicitly disable mangling via an attribute:
#[no_mangle]
fn this_symbol_wont_be_mangled() { ... }
> What took place of split stacks?
"Instead of segmented stacks we're going to rely on the OS and MMU to help us map pages lazily."
We have a module system. So we have to do name mangling to allow you to use multiple functions with the same name in different modules. This allows you to program without fear of annoying name collisions.
mod foo {
fn f() {}
}
mod bar {
fn f() {}
}
Stack checks that abort if you run out of stack (like MSVC's __chkstk). It would be nice to just replace it with guard pages where available, and we can probably do that in future versions.
> an example is to use weak aliasing of dummy functions - but this is sort of elf dependent (I have no idea how or if weak aliasing works in pe). I think this is an area that needs to be improved.
How does this allow the linker to throw away unused functions? The reason we use function and data sections is to allow the static linker to remove dead code (which is a lot for many programs).
In any case, it wouldn't obviate the need for bounds checking. It's possible to index into an array given information known only at runtime, which means that the check for whether that index is valid needs to happen at runtime.