@@ -1384,6 +1384,30 @@ mod prim_usize {}
13841384/// work on references as well as they do on owned values! The implementations described here are
13851385/// meant for generic contexts, where the final type `T` is a type parameter or otherwise not
13861386/// locally known.
1387+ ///
1388+ /// # Safety
1389+ ///
1390+ /// For all types, `T: ?Sized`, and for all `t: &T` or `t: &mut T`, when such values cross an API
1391+ /// boundary, the following invariants must generally be upheld:
1392+ ///
1393+ /// * `t` is aligned to `align_of_val(t)`
1394+ /// * `t` is dereferenceable for `size_of_val(t)` many bytes
1395+ ///
1396+ /// If `t` points at address `a`, being "dereferenceable" for N bytes means that the memory range
1397+ /// `[a, a + N)` is all contained within a single [allocated object].
1398+ ///
1399+ /// For instance, this means that unsafe code in a safe function may assume these invariants are
1400+ /// ensured of arguments passed by the caller, and it may assume that these invariants are ensured
1401+ /// of return values from any safe functions it calls. In most cases, the inverse is also true:
1402+ /// unsafe code must not violate these invariants when passing arguments to safe functions or
1403+ /// returning values from safe functions; such violations may result in undefined behavior. Where
1404+ /// exceptions to this latter requirement exist, they will be called out explicitly in documentation.
1405+ ///
1406+ /// It is not decided yet whether unsafe code may violate these invariants temporarily on internal
1407+ /// data. As a consequence, unsafe code which violates these invariants temporarily on internal data
1408+ /// may become unsound in future versions of Rust depending on how this question is decided.
1409+ ///
1410+ /// [allocated object]: ptr#allocated-object
13871411#[ stable( feature = "rust1" , since = "1.0.0" ) ]
13881412mod prim_ref { }
13891413
0 commit comments