Skip to content

Commit 0dc9e2a

Browse files
committed
improve wrapping_ docs
1 parent aa72b1d commit 0dc9e2a

File tree

1 file changed

+112
-26
lines changed

1 file changed

+112
-26
lines changed

src/libcore/ptr/mod.rs

+112-26
Original file line numberDiff line numberDiff line change
@@ -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

Comments
 (0)