[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe Code #21159

petrochenkov · 2015-01-14T21:27:02Z

It is an important topic to cover, but I'm not 100% sure I got everything right. Please, review / correct.

Somewhat related issue: #16022

… Code

rust-highfive · 2015-01-14T21:27:11Z

r? @steveklabnik

(rust_highfive has picked a reviewer for you, use r? to override)

steveklabnik · 2015-01-14T21:58:18Z

src/doc/trpl/unsafe.md

@@ -49,32 +49,16 @@ and mutable (`&mut`) references have some aliasing and freezing
 guarantees, required for memory safety.

 In particular, if you have an `&T` reference, then the `T` must not be
-modified through that reference or any other reference. There are some
+modified through that reference or any other reference or pointer and must not
+alias with any `&mut` reference. There are some
 standard library types, e.g. `Cell` and `RefCell`, that provide inner


it'd be nice to wrap this whole paragraph rather than have the weird line break here

steveklabnik · 2015-01-14T21:59:56Z

I like this expasion! I'd like someone else to review this for content too, as I lack experience in this area.

nagisa · 2015-01-14T23:12:34Z

src/doc/trpl/unsafe.md

+Several examples can give a better comprehension of the reference and pointer aliasing rules.
+
+First of all, using `unsafe` code to incorrectly circumvent and violate the
+restrictions on references leads to undefined behaviour. For example,


Is there any way to “correctly” circumvent the aliasing rules? If not, I’d probably remove the word. I’d also remove either “circumvent” or “violate”, since they’re synonymous.

First of all, using unsafe code to circumvent the restrictions on references leads to undefined behaviour.

petrochenkov · 2015-01-20T16:35:31Z

Bump.

r? @alexcrichton
Or someone else?

What bothers me is that the description (e.g. "Raw pointers can alias with anything") is not really true, for example if in the second example we convert the reference r into raw pointer (let r = r as *mut i32;), the assignment val2 = *r; will still be optimized out, because the raw pointer r is based on the reference r. But at the same time I think this PR is mostly an improvement compared to the current text.

Should I close this PR? Or improve it somehow? My goal is to keep things practical, without precise definitions (which belong to the reference, not to the ~~guide~~book).

alexcrichton · 2015-01-21T07:04:02Z

r? @steveklabnik

steveklabnik · 2015-01-22T16:32:13Z

@alexcrichton does this mean you're happy with the content? I explicitly asked for a second reviewer upthread, I'm happy if it's accurate.

alexcrichton · 2015-01-22T17:43:45Z

Oh sorry, I'll take a look.

alexcrichton · 2015-01-22T17:47:01Z

src/doc/trpl/unsafe.md

+
+fn main() {
+    let mut val_cell = UnsafeCell { value: 1i32 };
+    unsafe { f_cell(&mut val_cell.value, &mut val_cell) };


When not done in statics, the more conventional way to construct an UnsafeCell is via UnsafeCell::new and using the .get() method to get out a raw pointer.

But this piece of code is not conventional, UnsafeCell is explained here, not used :)
So I pursue the maximum transparency and ability to quickly substitute UnsafeCell with a user-defined structure to see the difference in behavior.

alexcrichton · 2015-01-22T17:49:28Z

Hm, I'm also not quite sure about this. I don't think I'm personally comfortable enough signing off on this, it's documenting some guarantees which sound reasonable, but we'd probably want to be pretty careful in this area.

I suspect that we'd want to clarify documentation like this in part of a general effort to clarify the precise boundaries of unsafe code and what is/isn't possible.

zwarich · 2015-01-22T21:31:27Z

src/doc/trpl/unsafe.md

-mutability by replacing compile time guarantees with dynamic checks at
-runtime.
+modified through that reference or any other reference or pointer and must not
+alias with any `&mut` reference. There are some standard library types, e.g.


Distinguishing between pointers and references seems a bit strange and overly verbose. It seems like we should just use a single word to refer to all pointer types. The language reference refers to them as 'pointers', but I've noticed in the past that some people in the Rust community dislike the P-word.

I can adjust the text to use the term "reference" for &T/&mut T, "raw pointer" for *const T/*mut T and "pointer" for both references and raw pointers. Would it be ok?

zwarich · 2015-01-22T22:31:41Z

To elaborate on my comment to the PR, I think it is impossible to describe correct rules here without involving lifetime variables. For example, this code from libcore/cell.rs is a safe use of unsafe code:

fn deref_mut<'a>(&'a mut self) -> &'a mut T {
    unsafe { &mut *self._parent.value.get() }
}

But this code, only differing in lifetime variables, is not:

fn deref_mut<'a>(&'a mut self) -> &'static mut T {
    unsafe { &mut *self._parent.value.get() }
}

petrochenkov · 2015-01-23T09:08:53Z

@zwarich
Dunno, I see the dangling references to be a completely different problem from references blind to changes in the referent due to aliasing assumptions.

petrochenkov · 2015-01-23T09:33:44Z

@alexcrichton

it's documenting some guarantees which sound reasonable, but we'd probably want to be pretty careful in this area.
I suspect that we'd want to clarify documentation like this in part of a general effort to clarify the precise boundaries of unsafe code and what is/isn't possible.

Is the book a normative document? I assumed that it serves a teaching purpose and can contain acceptable degree of simplifications and half-truths (but not plain lie) compared to the formal reference.

zwarich · 2015-01-23T18:23:10Z

@petrochenkov The problem I pointed out isn't a problem of dangling references. It's about the obligations that unsafe code has to fulfill to safe code when it creates new pointers with restricted aliasing.

The other major problem with these rules is that it forbids creating raw derived pointers from &mut pointers and using them to perform writes. This means that you can't do something like call memcpy on data that you have via an &mut.

petrochenkov · 2015-01-23T19:28:09Z

The other major problem with these rules is that it forbids creating raw derived pointers from &mut pointers and using them to perform writes. This means that you can't do something like call memcpy on data that you have via an &mut.

Yes, that's a problem, I continue to study the compiler, but the precise actual rules are still not clear for me - that's why I asked for possible improvements and corrections.
(I'd be happy if this chapter of the book were written by people who actually wrote the backend, but so far there are no signs that this will happen soon.)

petrochenkov · 2015-01-25T21:52:18Z

Closing for now.

aidanhs · 2016-02-29T01:19:00Z

The whole aliasing thing is being discussed over at rust-lang/rfcs#1447

[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe…

312d36c

… Code

rust-highfive assigned steveklabnik Jan 14, 2015

steveklabnik reviewed Jan 14, 2015
View reviewed changes

nagisa reviewed Jan 14, 2015
View reviewed changes

Incorporate the feedback

c9be0d8

rust-highfive assigned alexcrichton and unassigned steveklabnik Jan 20, 2015

rust-highfive assigned steveklabnik and unassigned alexcrichton Jan 21, 2015

alexcrichton assigned alexcrichton and unassigned steveklabnik Jan 22, 2015

alexcrichton reviewed Jan 22, 2015
View reviewed changes

zwarich reviewed Jan 22, 2015
View reviewed changes

petrochenkov closed this Jan 25, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe Code #21159

[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe Code #21159

petrochenkov commented Jan 14, 2015

rust-highfive commented Jan 14, 2015

steveklabnik Jan 14, 2015

steveklabnik commented Jan 14, 2015

nagisa Jan 14, 2015

petrochenkov commented Jan 20, 2015

alexcrichton commented Jan 21, 2015

steveklabnik commented Jan 22, 2015

alexcrichton commented Jan 22, 2015

alexcrichton Jan 22, 2015

petrochenkov Jan 23, 2015

alexcrichton commented Jan 22, 2015

zwarich Jan 22, 2015

petrochenkov Jan 23, 2015

zwarich commented Jan 22, 2015

petrochenkov commented Jan 23, 2015

petrochenkov commented Jan 23, 2015

zwarich commented Jan 23, 2015

petrochenkov commented Jan 23, 2015

petrochenkov commented Jan 25, 2015

aidanhs commented Feb 29, 2016

[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe Code #21159

[Docs] Expand the section about pointer aliasing in TRPL: 4.2. Unsafe Code #21159

Conversation

petrochenkov commented Jan 14, 2015

rust-highfive commented Jan 14, 2015

steveklabnik Jan 14, 2015

Choose a reason for hiding this comment

steveklabnik commented Jan 14, 2015

nagisa Jan 14, 2015

Choose a reason for hiding this comment

petrochenkov commented Jan 20, 2015

alexcrichton commented Jan 21, 2015

steveklabnik commented Jan 22, 2015

alexcrichton commented Jan 22, 2015

alexcrichton Jan 22, 2015

Choose a reason for hiding this comment

petrochenkov Jan 23, 2015

Choose a reason for hiding this comment

alexcrichton commented Jan 22, 2015

zwarich Jan 22, 2015

Choose a reason for hiding this comment

petrochenkov Jan 23, 2015

Choose a reason for hiding this comment

zwarich commented Jan 22, 2015

petrochenkov commented Jan 23, 2015

petrochenkov commented Jan 23, 2015

zwarich commented Jan 23, 2015

petrochenkov commented Jan 23, 2015

petrochenkov commented Jan 25, 2015

aidanhs commented Feb 29, 2016