@@ -1141,10 +1141,12 @@ impl<T: ?Sized> *const T {
11411141 /// Extension. As such, memory acquired directly from allocators or memory
11421142 /// mapped files *may* be too large to handle with this function.
11431143 ///
1144- /// Consider using `wrapping_offset` instead if these constraints are
1144+ /// Consider using [ `wrapping_offset`] instead if these constraints are
11451145 /// difficult to satisfy. The only advantage of this method is that it
11461146 /// enables more aggressive compiler optimizations.
11471147 ///
1148+ /// [`wrapping_offset`]: #method.wrapping_offset
1149+ ///
11481150 /// # Examples
11491151 ///
11501152 /// Basic usage:
@@ -1173,15 +1175,26 @@ impl<T: ?Sized> *const T {
11731175 ///
11741176 /// The resulting pointer does not need to be in bounds, but it is
11751177 /// potentially hazardous to dereference (which requires `unsafe`).
1176- /// In particular, the resulting pointer may *not* be used to access a
1177- /// different allocated object than the one `self` points to. In other
1178- /// words, `x.wrapping_offset(y.wrapping_offset_from(x))` is
1178+ ///
1179+ /// In particular, the resulting pointer remains attached to the same allocated
1180+ /// object that `self` points to. It may *not* be used to access a
1181+ /// different allocated object. Note that in Rust,
1182+ /// every (stack-allocated) variable is considered a separate allocated object.
1183+ ///
1184+ /// In other words, `x.wrapping_offset(y.wrapping_offset_from(x))` is
11791185 /// *not* the same as `y`, and dereferencing it is undefined behavior
11801186 /// unless `x` and `y` point into the same allocated object.
11811187 ///
1182- /// Always use `.offset(count)` instead when possible, because `offset`
1183- /// allows the compiler to optimize better. If you need to cross object
1184- /// boundaries, cast the pointer to an integer and do the arithmetic there.
1188+ /// Compared to [`offset`], this method basically delays the requirement of staying
1189+ /// within the same allocated object: [`offset`] is immediate Undefined Behavior when
1190+ /// crossing object boundaries; `wrapping_offset` produces a pointer but still leads
1191+ /// to Undefined Behavior if that pointer is dereferenced. [`offset`] can be optimized
1192+ /// better and is thus preferrable in performance-sensitive code.
1193+ ///
1194+ /// If you need to cross object boundaries, cast the pointer to an integer and
1195+ /// do the arithmetic there.
1196+ ///
1197+ /// [`offset`]: #method.offset
11851198 ///
11861199 /// # Examples
11871200 ///
@@ -1361,10 +1374,12 @@ impl<T: ?Sized> *const T {
13611374 /// Extension. As such, memory acquired directly from allocators or memory
13621375 /// mapped files *may* be too large to handle with this function.
13631376 ///
1364- /// Consider using `wrapping_offset` instead if these constraints are
1377+ /// Consider using [`wrapping_add`] instead if these constraints are
13651378 /// difficult to satisfy. The only advantage of this method is that it
13661379 /// enables more aggressive compiler optimizations.
13671380 ///
1381+ /// [`wrapping_add`]: #method.wrapping_add
1382+ ///
13681383 /// # Examples
13691384 ///
13701385 /// Basic usage:
@@ -1419,10 +1434,12 @@ impl<T: ?Sized> *const T {
14191434 /// Extension. As such, memory acquired directly from allocators or memory
14201435 /// mapped files *may* be too large to handle with this function.
14211436 ///
1422- /// Consider using `wrapping_offset` instead if these constraints are
1437+ /// Consider using [`wrapping_sub`] instead if these constraints are
14231438 /// difficult to satisfy. The only advantage of this method is that it
14241439 /// enables more aggressive compiler optimizations.
14251440 ///
1441+ /// [`wrapping_sub`]: #method.wrapping_sub
1442+ ///
14261443 /// # Examples
14271444 ///
14281445 /// Basic usage:
@@ -1455,8 +1472,21 @@ impl<T: ?Sized> *const T {
14551472 /// The resulting pointer does not need to be in bounds, but it is
14561473 /// potentially hazardous to dereference (which requires `unsafe`).
14571474 ///
1458- /// Always use `.add(count)` instead when possible, because `add`
1459- /// allows the compiler to optimize better.
1475+ /// In particular, the resulting pointer remains attached to the same allocated
1476+ /// object that `self` points to. It may *not* be used to access a
1477+ /// different allocated object. Note that in Rust,
1478+ /// every (stack-allocated) variable is considered a separate allocated object.
1479+ ///
1480+ /// Compared to [`add`], this method basically delays the requirement of staying
1481+ /// within the same allocated object: [`add`] is immediate Undefined Behavior when
1482+ /// crossing object boundaries; `wrapping_add` produces a pointer but still leads
1483+ /// to Undefined Behavior if that pointer is dereferenced. [`add`] can be optimized
1484+ /// better and is thus preferrable in performance-sensitive code.
1485+ ///
1486+ /// If you need to cross object boundaries, cast the pointer to an integer and
1487+ /// do the arithmetic there.
1488+ ///
1489+ /// [`add`]: #method.add
14601490 ///
14611491 /// # Examples
14621492 ///
@@ -1496,8 +1526,21 @@ impl<T: ?Sized> *const T {
14961526 /// The resulting pointer does not need to be in bounds, but it is
14971527 /// potentially hazardous to dereference (which requires `unsafe`).
14981528 ///
1499- /// Always use `.sub(count)` instead when possible, because `sub`
1500- /// allows the compiler to optimize better.
1529+ /// In particular, the resulting pointer remains attached to the same allocated
1530+ /// object that `self` points to. It may *not* be used to access a
1531+ /// different allocated object. Note that in Rust,
1532+ /// every (stack-allocated) variable is considered a separate allocated object.
1533+ ///
1534+ /// Compared to [`sub`], this method basically delays the requirement of staying
1535+ /// within the same allocated object: [`sub`] is immediate Undefined Behavior when
1536+ /// crossing object boundaries; `wrapping_sub` produces a pointer but still leads
1537+ /// to Undefined Behavior if that pointer is dereferenced. [`sub`] can be optimized
1538+ /// better and is thus preferrable in performance-sensitive code.
1539+ ///
1540+ /// If you need to cross object boundaries, cast the pointer to an integer and
1541+ /// do the arithmetic there.
1542+ ///
1543+ /// [`sub`]: #method.sub
15011544 ///
15021545 /// # Examples
15031546 ///
@@ -1780,10 +1823,12 @@ impl<T: ?Sized> *mut T {
17801823 /// Extension. As such, memory acquired directly from allocators or memory
17811824 /// mapped files *may* be too large to handle with this function.
17821825 ///
1783- /// Consider using `wrapping_offset` instead if these constraints are
1826+ /// Consider using [ `wrapping_offset`] instead if these constraints are
17841827 /// difficult to satisfy. The only advantage of this method is that it
17851828 /// enables more aggressive compiler optimizations.
17861829 ///
1830+ /// [`wrapping_offset`]: #method.wrapping_offset
1831+ ///
17871832 /// # Examples
17881833 ///
17891834 /// Basic usage:
@@ -1811,15 +1856,26 @@ impl<T: ?Sized> *mut T {
18111856 ///
18121857 /// The resulting pointer does not need to be in bounds, but it is
18131858 /// potentially hazardous to dereference (which requires `unsafe`).
1814- /// In particular, the resulting pointer may *not* be used to access a
1815- /// different allocated object than the one `self` points to. In other
1816- /// words, `x.wrapping_offset(y.wrapping_offset_from(x))` is
1859+ ///
1860+ /// In particular, the resulting pointer remains attached to the same allocated
1861+ /// object that `self` points to. It may *not* be used to access a
1862+ /// different allocated object. Note that in Rust,
1863+ /// every (stack-allocated) variable is considered a separate allocated object.
1864+ ///
1865+ /// In other words, `x.wrapping_offset(y.wrapping_offset_from(x))` is
18171866 /// *not* the same as `y`, and dereferencing it is undefined behavior
18181867 /// unless `x` and `y` point into the same allocated object.
18191868 ///
1820- /// Always use `.offset(count)` instead when possible, because `offset`
1821- /// allows the compiler to optimize better. If you need to cross object
1822- /// boundaries, cast the pointer to an integer and do the arithmetic there.
1869+ /// Compared to [`offset`], this method basically delays the requirement of staying
1870+ /// within the same allocated object: [`offset`] is immediate Undefined Behavior when
1871+ /// crossing object boundaries; `wrapping_offset` produces a pointer but still leads
1872+ /// to Undefined Behavior if that pointer is dereferenced. [`offset`] can be optimized
1873+ /// better and is thus preferrable in performance-sensitive code.
1874+ ///
1875+ /// If you need to cross object boundaries, cast the pointer to an integer and
1876+ /// do the arithmetic there.
1877+ ///
1878+ /// [`offset`]: #method.offset
18231879 ///
18241880 /// # Examples
18251881 ///
@@ -2032,10 +2088,12 @@ impl<T: ?Sized> *mut T {
20322088 /// Extension. As such, memory acquired directly from allocators or memory
20332089 /// mapped files *may* be too large to handle with this function.
20342090 ///
2035- /// Consider using `wrapping_offset` instead if these constraints are
2091+ /// Consider using [`wrapping_add`] instead if these constraints are
20362092 /// difficult to satisfy. The only advantage of this method is that it
20372093 /// enables more aggressive compiler optimizations.
20382094 ///
2095+ /// [`wrapping_add`]: #method.wrapping_add
2096+ ///
20392097 /// # Examples
20402098 ///
20412099 /// Basic usage:
@@ -2090,10 +2148,12 @@ impl<T: ?Sized> *mut T {
20902148 /// Extension. As such, memory acquired directly from allocators or memory
20912149 /// mapped files *may* be too large to handle with this function.
20922150 ///
2093- /// Consider using `wrapping_offset` instead if these constraints are
2151+ /// Consider using [`wrapping_sub`] instead if these constraints are
20942152 /// difficult to satisfy. The only advantage of this method is that it
20952153 /// enables more aggressive compiler optimizations.
20962154 ///
2155+ /// [`wrapping_sub`]: #method.wrapping_sub
2156+ ///
20972157 /// # Examples
20982158 ///
20992159 /// Basic usage:
@@ -2126,8 +2186,21 @@ impl<T: ?Sized> *mut T {
21262186 /// The resulting pointer does not need to be in bounds, but it is
21272187 /// potentially hazardous to dereference (which requires `unsafe`).
21282188 ///
2129- /// Always use `.add(count)` instead when possible, because `add`
2130- /// allows the compiler to optimize better.
2189+ /// In particular, the resulting pointer remains attached to the same allocated
2190+ /// object that `self` points to. It may *not* be used to access a
2191+ /// different allocated object. Note that in Rust,
2192+ /// every (stack-allocated) variable is considered a separate allocated object.
2193+ ///
2194+ /// Compared to [`add`], this method basically delays the requirement of staying
2195+ /// within the same allocated object: [`add`] is immediate Undefined Behavior when
2196+ /// crossing object boundaries; `wrapping_add` produces a pointer but still leads
2197+ /// to Undefined Behavior if that pointer is dereferenced. [`add`] can be optimized
2198+ /// better and is thus preferrable in performance-sensitive code.
2199+ ///
2200+ /// If you need to cross object boundaries, cast the pointer to an integer and
2201+ /// do the arithmetic there.
2202+ ///
2203+ /// [`add`]: #method.add
21312204 ///
21322205 /// # Examples
21332206 ///
@@ -2167,8 +2240,21 @@ impl<T: ?Sized> *mut T {
21672240 /// The resulting pointer does not need to be in bounds, but it is
21682241 /// potentially hazardous to dereference (which requires `unsafe`).
21692242 ///
2170- /// Always use `.sub(count)` instead when possible, because `sub`
2171- /// allows the compiler to optimize better.
2243+ /// In particular, the resulting pointer remains attached to the same allocated
2244+ /// object that `self` points to. It may *not* be used to access a
2245+ /// different allocated object. Note that in Rust,
2246+ /// every (stack-allocated) variable is considered a separate allocated object.
2247+ ///
2248+ /// Compared to [`sub`], this method basically delays the requirement of staying
2249+ /// within the same allocated object: [`sub`] is immediate Undefined Behavior when
2250+ /// crossing object boundaries; `wrapping_sub` produces a pointer but still leads
2251+ /// to Undefined Behavior if that pointer is dereferenced. [`sub`] can be optimized
2252+ /// better and is thus preferrable in performance-sensitive code.
2253+ ///
2254+ /// If you need to cross object boundaries, cast the pointer to an integer and
2255+ /// do the arithmetic there.
2256+ ///
2257+ /// [`sub`]: #method.sub
21722258 ///
21732259 /// # Examples
21742260 ///
0 commit comments