On Fri, Feb 22, 2019 at 1:00 AM Jeff Walden <jwalden+...@mit.edu> wrote:
>
> On 2/17/19 11:40 PM, Henri Sivonen wrote:
> > Rust, which combines the
> > perf benefits of -fstrict-aliasing with the understandability of
> > -fno-strict-aliasing?
>
> This is not really true of Rust. Rust's memory model is not really defined
> yet https://doc.rust-lang.org/reference/memory-model.html but from what I've
> been able to read as to how you're "supposed" to and "should" use the
> language in unsafe code and through FFI, it *does* require the same sorts of
> things as C++ in "you can't dereference a pointer/reference unless it
> contains a well-formed value of the type of the pointer/reference". Just,
> Rust has somewhat more tools that hide away this unsafety so you don't often
> manually bash on memory yourself in that manner.
Requiring a dereferenced pointer to point to a value that is
well-formed according to the type of the pointer is *very* different
from having requirements on how the value was written ("effective
type"). E.g. all possible bit patterns of f64 are well-formed bit
patterns for u64, so in Rust it's permissible to use a u64-typed
pointer to access a value that was created as f64. However, in C++
(without -fno-strict-aliasing, of course), if the "effective type" of
a pointee is double, i.e. it was written as double, it's not
permissible to access the value via a uint64_t-type pointer.
In fact, the Rust standard library even provides an API for such viewing:
https://doc.rust-lang.org/std/primitive.slice.html#method.align_to
The unsafety remark is not in terms of aliasing but in terms of
*value* transmutability. The method is fully safe when U is a type for
which all bit patterns of U's size are valid values. (I'm a bit
disappointed that there isn't a safe method to that effect with a
trait bound to a trait that says that all bit patterns are valid. Then
primitive integers and SIMD vectors of integer lanes could implement
that marker trait.)
> As a practical matter, I don't honestly see how Rust can avoid having a
> memory model very similar to C++'s, including with respect to aliasing, even
> if they're not there *formally* yet.
As far as I'm aware, Ralf Jung, who is working on the formalization,
is against introducing *type-based* alias analysis to Rust. Unsafe
Rust has informal and will have formal aliasing rules, but all
indications are that they won't be *type-based*.
See
https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html
https://www.ralfj.de/blog/2018/11/16/stacked-borrows-implementation.html
https://www.ralfj.de/blog/2018/12/26/stacked-borrows-barriers.html
for the aliasing rule formulation that does not involve type-based
alias analysis.
--
Henri Sivonen
hsivo...@mozilla.com
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
