---

yaml
---
r: 275005
b: refs/heads/stable
c: 37a952a
h: refs/heads/master
i:
  275003: 4598fb0

Author: sandeep-datta

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: e06d2ad9fcd5027bcaac5b08fc9aa39a49d0ecd3
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: c0221c8897db309a79990367476177b1230bb264
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: a6fedc85bfec568a404c4a78d9c7faef12937695
+refs/heads/stable: 37a952a672ca79bfcc41795e378a710c196a557a
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/src/doc/book/ownership.md

@@ -166,6 +166,8 @@ Rust’s safety guarantees by introducing a data race if one could access both
 For example if we truncated the vector to just two elements through `v2`:
 
 ```rust
+# let v = vec![1, 2, 3];
+# let v2 = v;
 v2.truncate(2);
 ```
 
@@ -174,7 +176,9 @@ would not know that the heap data has been truncated. Now, the part of the
 vector `v1` on the stack does not agree with the corresponding part on the
 heap. `v1` still thinks there are three elements in the vector and will
 happily let us access the non existent element `v1[2]` but as you might
-already know this is a recipe for disaster (might lead to a segfault).
+already know this is a recipe for disaster. Especially because it might lead
+to a segmentation fault or worse allow an unauthorized user to read from
+memory to which they don't have access.
 
 This is why Rust forbids using `v` after we’ve done the move.