|
237 | 237 | //! pointer. For code which *does* cast a usize to a pointer, the scope of the change depends |
238 | 238 | //! on exactly what you're doing. |
239 | 239 | //! |
240 | | -//! In general you just need to make sure that if you want to convert a usize address to a |
| 240 | +//! In general, you just need to make sure that if you want to convert a usize address to a |
241 | 241 | //! pointer and then use that pointer to read/write memory, you need to keep around a pointer |
242 | 242 | //! that has sufficient provenance to perform that read/write itself. In this way all of your |
243 | 243 | //! casts from an address to a pointer are essentially just applying offsets/indexing. |
|
309 | 309 | //! i.e. the usual "ZSTs are fake, do what you want" rules apply *but* this only applies |
310 | 310 | //! for actual forgery (integers cast to pointers). If you borrow some struct's field |
311 | 311 | //! that *happens* to be zero-sized, the resulting pointer will have provenance tied to |
312 | | -//! that allocation and it will still get invalidated if the allocation gets deallocated. |
| 312 | +//! that allocation, and it will still get invalidated if the allocation gets deallocated. |
313 | 313 | //! In the future we may introduce an API to make such a forged allocation explicit. |
314 | 314 | //! |
315 | 315 | //! * [`wrapping_offset`][] a pointer outside its provenance. This includes pointers |
@@ -698,7 +698,7 @@ pub const fn dangling_mut<T>() -> *mut T { |
698 | 698 | /// |
699 | 699 | /// If there is no 'exposed' provenance that justifies the way this pointer will be used, |
700 | 700 | /// the program has undefined behavior. In particular, the aliasing rules still apply: pointers |
701 | | -/// and references that have been invalidated due to aliasing accesses cannot be usedany more, |
| 701 | +/// and references that have been invalidated due to aliasing accesses cannot be usedanymore, |
702 | 702 | /// even if they have been exposed! |
703 | 703 | /// |
704 | 704 | /// Note that there is no algorithm that decides which provenance will be used. You can think of this |
@@ -1097,7 +1097,7 @@ const unsafe fn swap_nonoverlapping_simple_untyped<T>(x: *mut T, y: *mut T, coun |
1097 | 1097 | // If we end up here, it's because we're using a simple type -- like |
1098 | 1098 | // a small power-of-two-sized thing -- or a special type with particularly |
1099 | 1099 | // large alignment, particularly SIMD types. |
1100 | | -// Thus we're fine just reading-and-writing it, as either it's small |
| 1100 | +// Thus, we're fine just reading-and-writing it, as either it's small |
1101 | 1101 | // and that works well anyway or it's special and the type's author |
1102 | 1102 | // presumably wanted things to be done in the larger chunk. |
1103 | 1103 |
|
@@ -1290,7 +1290,7 @@ pub const unsafe fn read<T>(src: *const T) -> T { |
1290 | 1290 | // provides enough information to know that this is a typed operation. |
1291 | 1291 |
|
1292 | 1292 | // However, as of March 2023 the compiler was not capable of taking advantage |
1293 | | -// of that information.Thus the implementation here switched to an intrinsic, |
| 1293 | +// of that information. Thus, the implementation here switched to an intrinsic, |
1294 | 1294 | // which lowers to `_0 = *src` in MIR, to address a few issues: |
1295 | 1295 | // |
1296 | 1296 | // - Using `MaybeUninit::assume_init` after a `copy_nonoverlapping` was not |
@@ -1570,7 +1570,7 @@ pub const unsafe fn write<T>(dst: *mut T, src: T) { |
1570 | 1570 | /// As a result, using `&packed.unaligned as *const FieldType` causes immediate |
1571 | 1571 | /// *undefined behavior* in your program. |
1572 | 1572 | /// |
1573 | | -/// Instead you must use the [`ptr::addr_of_mut!`](addr_of_mut) |
| 1573 | +/// Instead, you must use the [`ptr::addr_of_mut!`](addr_of_mut) |
1574 | 1574 | /// macro to create the pointer. You may use that returned pointer together with |
1575 | 1575 | /// this function. |
1576 | 1576 | /// |
|