@@ -1141,10 +1141,12 @@ impl<T: ?Sized> *const T {
1141
1141
/// Extension. As such, memory acquired directly from allocators or memory
1142
1142
/// mapped files *may* be too large to handle with this function.
1143
1143
///
1144
- /// Consider using `wrapping_offset` instead if these constraints are
1144
+ /// Consider using [ `wrapping_offset`] instead if these constraints are
1145
1145
/// difficult to satisfy. The only advantage of this method is that it
1146
1146
/// enables more aggressive compiler optimizations.
1147
1147
///
1148
+ /// [`wrapping_offset`]: #method.wrapping_offset
1149
+ ///
1148
1150
/// # Examples
1149
1151
///
1150
1152
/// Basic usage:
@@ -1173,15 +1175,26 @@ impl<T: ?Sized> *const T {
1173
1175
///
1174
1176
/// The resulting pointer does not need to be in bounds, but it is
1175
1177
/// 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
1179
1185
/// *not* the same as `y`, and dereferencing it is undefined behavior
1180
1186
/// unless `x` and `y` point into the same allocated object.
1181
1187
///
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
1185
1198
///
1186
1199
/// # Examples
1187
1200
///
@@ -1361,10 +1374,12 @@ impl<T: ?Sized> *const T {
1361
1374
/// Extension. As such, memory acquired directly from allocators or memory
1362
1375
/// mapped files *may* be too large to handle with this function.
1363
1376
///
1364
- /// Consider using `wrapping_offset` instead if these constraints are
1377
+ /// Consider using [`wrapping_add`] instead if these constraints are
1365
1378
/// difficult to satisfy. The only advantage of this method is that it
1366
1379
/// enables more aggressive compiler optimizations.
1367
1380
///
1381
+ /// [`wrapping_add`]: #method.wrapping_add
1382
+ ///
1368
1383
/// # Examples
1369
1384
///
1370
1385
/// Basic usage:
@@ -1419,10 +1434,12 @@ impl<T: ?Sized> *const T {
1419
1434
/// Extension. As such, memory acquired directly from allocators or memory
1420
1435
/// mapped files *may* be too large to handle with this function.
1421
1436
///
1422
- /// Consider using `wrapping_offset` instead if these constraints are
1437
+ /// Consider using [`wrapping_sub`] instead if these constraints are
1423
1438
/// difficult to satisfy. The only advantage of this method is that it
1424
1439
/// enables more aggressive compiler optimizations.
1425
1440
///
1441
+ /// [`wrapping_sub`]: #method.wrapping_sub
1442
+ ///
1426
1443
/// # Examples
1427
1444
///
1428
1445
/// Basic usage:
@@ -1455,8 +1472,21 @@ impl<T: ?Sized> *const T {
1455
1472
/// The resulting pointer does not need to be in bounds, but it is
1456
1473
/// potentially hazardous to dereference (which requires `unsafe`).
1457
1474
///
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
1460
1490
///
1461
1491
/// # Examples
1462
1492
///
@@ -1496,8 +1526,21 @@ impl<T: ?Sized> *const T {
1496
1526
/// The resulting pointer does not need to be in bounds, but it is
1497
1527
/// potentially hazardous to dereference (which requires `unsafe`).
1498
1528
///
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
1501
1544
///
1502
1545
/// # Examples
1503
1546
///
@@ -1780,10 +1823,12 @@ impl<T: ?Sized> *mut T {
1780
1823
/// Extension. As such, memory acquired directly from allocators or memory
1781
1824
/// mapped files *may* be too large to handle with this function.
1782
1825
///
1783
- /// Consider using `wrapping_offset` instead if these constraints are
1826
+ /// Consider using [ `wrapping_offset`] instead if these constraints are
1784
1827
/// difficult to satisfy. The only advantage of this method is that it
1785
1828
/// enables more aggressive compiler optimizations.
1786
1829
///
1830
+ /// [`wrapping_offset`]: #method.wrapping_offset
1831
+ ///
1787
1832
/// # Examples
1788
1833
///
1789
1834
/// Basic usage:
@@ -1811,15 +1856,26 @@ impl<T: ?Sized> *mut T {
1811
1856
///
1812
1857
/// The resulting pointer does not need to be in bounds, but it is
1813
1858
/// 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
1817
1866
/// *not* the same as `y`, and dereferencing it is undefined behavior
1818
1867
/// unless `x` and `y` point into the same allocated object.
1819
1868
///
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
1823
1879
///
1824
1880
/// # Examples
1825
1881
///
@@ -2032,10 +2088,12 @@ impl<T: ?Sized> *mut T {
2032
2088
/// Extension. As such, memory acquired directly from allocators or memory
2033
2089
/// mapped files *may* be too large to handle with this function.
2034
2090
///
2035
- /// Consider using `wrapping_offset` instead if these constraints are
2091
+ /// Consider using [`wrapping_add`] instead if these constraints are
2036
2092
/// difficult to satisfy. The only advantage of this method is that it
2037
2093
/// enables more aggressive compiler optimizations.
2038
2094
///
2095
+ /// [`wrapping_add`]: #method.wrapping_add
2096
+ ///
2039
2097
/// # Examples
2040
2098
///
2041
2099
/// Basic usage:
@@ -2090,10 +2148,12 @@ impl<T: ?Sized> *mut T {
2090
2148
/// Extension. As such, memory acquired directly from allocators or memory
2091
2149
/// mapped files *may* be too large to handle with this function.
2092
2150
///
2093
- /// Consider using `wrapping_offset` instead if these constraints are
2151
+ /// Consider using [`wrapping_sub`] instead if these constraints are
2094
2152
/// difficult to satisfy. The only advantage of this method is that it
2095
2153
/// enables more aggressive compiler optimizations.
2096
2154
///
2155
+ /// [`wrapping_sub`]: #method.wrapping_sub
2156
+ ///
2097
2157
/// # Examples
2098
2158
///
2099
2159
/// Basic usage:
@@ -2126,8 +2186,21 @@ impl<T: ?Sized> *mut T {
2126
2186
/// The resulting pointer does not need to be in bounds, but it is
2127
2187
/// potentially hazardous to dereference (which requires `unsafe`).
2128
2188
///
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
2131
2204
///
2132
2205
/// # Examples
2133
2206
///
@@ -2167,8 +2240,21 @@ impl<T: ?Sized> *mut T {
2167
2240
/// The resulting pointer does not need to be in bounds, but it is
2168
2241
/// potentially hazardous to dereference (which requires `unsafe`).
2169
2242
///
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
2172
2258
///
2173
2259
/// # Examples
2174
2260
///
0 commit comments