Update kani::mem pointer validity documentation (#4092)

https://github.com/rust-lang/rust/pull/117329/files#diff-c175d4e27676febf62c061d31cf9756d256b46e2e44cc6b3177d4ff75e932567L18-L29
changed the pointer safety documentation. We changed our models
accordingly:


https://github.com/model-checking/kani/blob/92bc45da85ff70edb5a341f5566f150721150247/library/kani_core/src/mem.rs#L186-L190

but forgot to update the documentation.

See https://doc.rust-lang.org/beta/core/ptr/index.html for the current
documentation; the point of this PR is to 1) update our docs to match
this reference and 2) state which of the points Kani can verify.

Resolves #4087

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.

Author: Carolyn Zech

library/kani_core/src/lib.rs

@@ -82,22 +82,15 @@ macro_rules! kani_lib {
             //! This module contains functions useful for checking unsafe memory access.
             //!
             //! Given the following validity rules provided in the Rust documentation:
-            //! <https://doc.rust-lang.org/std/ptr/index.html> (accessed Feb 6th, 2024)
+            //! <https://doc.rust-lang.org/std/ptr/index.html> (accessed May 20th, 2025)
             //!
-            //! 1. A null pointer is never valid, not even for accesses of size zero.
-            //! 2. For a pointer to be valid, it is necessary, but not always sufficient, that the pointer
+            //! 1. For memory accesses of size zero, every pointer is valid, including the null pointer.
+            //!    The following points are only concerned with non-zero-sized accesses.
+            //! 2. A null pointer is never valid.
+            //! 3. For a pointer to be valid, it is necessary, but not always sufficient, that the pointer
             //!    be dereferenceable: the memory range of the given size starting at the pointer must all be
             //!    within the bounds of a single allocated object. Note that in Rust, every (stack-allocated)
             //!    variable is considered a separate allocated object.
-            //!    ~~Even for operations of size zero, the pointer must not be pointing to deallocated memory,
-            //!    i.e., deallocation makes pointers invalid even for zero-sized operations.~~
-            //!    ZST access is not OK for any pointer.
-            //!    See: <https://github.com/rust-lang/unsafe-code-guidelines/issues/472>
-            //! 3. However, casting any non-zero integer literal to a pointer is valid for zero-sized
-            //!    accesses, even if some memory happens to exist at that address and gets deallocated.
-            //!    This corresponds to writing your own allocator: allocating zero-sized objects is not very
-            //!    hard. The canonical way to obtain a pointer that is valid for zero-sized accesses is
-            //!    `NonNull::dangling`.
             //! 4. All accesses performed by functions in this module are non-atomic in the sense of atomic
             //!    operations used to synchronize between threads.
             //!    This means it is undefined behavior to perform two concurrent accesses to the same location
@@ -108,13 +101,7 @@ macro_rules! kani_lib {
             //!    object is live and no reference (just raw pointers) is used to access the same memory.
             //!    That is, reference and pointer accesses cannot be interleaved.
             //!
-            //! Kani is able to verify #1 and #2 today.
-            //!
-            //! For #3, we are overly cautious, and Kani will only consider zero-sized pointer access safe if
-            //! the address matches `NonNull::<()>::dangling()`.
-            //! The way Kani tracks provenance is not enough to check if the address was the result of a cast
-            //! from a non-zero integer literal.
-            //!
+            //! Kani is able to verify #1, #2, and #3 today.
             kani_core::kani_mem!(std);
         }