doc: Added commas where needed · model-checking/verify-rust-std@7912329 (original) (raw)

`@@ -237,7 +237,7 @@

237

`//! pointer. For code which does cast a usize to a pointer, the scope of the change depends

238

`//! on exactly what you're doing.

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

`//! pointer and then use that pointer to read/write memory, you need to keep around a pointer

242

`//! that has sufficient provenance to perform that read/write itself. In this way all of your

243

`//! casts from an address to a pointer are essentially just applying offsets/indexing.

309

`//! i.e. the usual "ZSTs are fake, do what you want" rules apply but this only applies

310

`//! for actual forgery (integers cast to pointers). If you borrow some struct's field

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

`//! In the future we may introduce an API to make such a forged allocation explicit.

314

`//!

315

`` //! * [wrapping_offset][] a pointer outside its provenance. This includes pointers

`@@ -698,7 +698,7 @@ pub const fn dangling_mut() -> *mut T {

698

`///

699

`/// If there is no 'exposed' provenance that justifies the way this pointer will be used,

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 used any more,

701

/// and references that have been invalidated due to aliasing accesses cannot be used anymore,

702

`/// even if they have been exposed!

703

`///

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(x: *mut T, y: *mut T, coun

1097

`// If we end up here, it's because we're using a simple type -- like

1098

`// a small power-of-two-sized thing -- or a special type with particularly

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

`// and that works well anyway or it's special and the type's author

1102

`// presumably wanted things to be done in the larger chunk.

1103

`@@ -1290,7 +1290,7 @@ pub const unsafe fn read(src: *const T) -> T {

1290

`// provides enough information to know that this is a typed operation.

1291

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

`` // which lowers to _0 = *src in MIR, to address a few issues:

1295

`//

1296

`` // - Using MaybeUninit::assume_init after a copy_nonoverlapping was not

`@@ -1570,7 +1570,7 @@ pub const unsafe fn write(dst: *mut T, src: T) {

1570

`` /// As a result, using &packed.unaligned as *const FieldType causes immediate

1571

`/// undefined behavior in your program.

1572

`///

1573

`` -

/// Instead you must use the ptr::addr_of_mut!

1573

`` +

/// Instead, you must use the ptr::addr_of_mut!

1574

`/// macro to create the pointer. You may use that returned pointer together with

1575

`/// this function.

1576

`///