Valid locations also need valid lifetimes
Out-of-bounds access violates a permitted range, while use-after-free accesses storage after its former allocation has ceased to be valid. A numerical address alone does not distinguish them. Remaining within an allocation does not establish a valid object lifetime, and a live object does not permit every index.
Languages impose additional conditions involving alignment, valid representations, and aliasing. The Rust Reference includes dangling or misaligned accesses and violations of reference requirements among undefined behaviors. Memory safety is therefore more specific than simply avoiding an observed segmentation fault.
Restrictions, checks, and safe interfaces
Languages can reject invalid programs statically or check access conditions at runtime. Rust ownership and borrowing contribute static restrictions. Implementations performing raw-pointer operations through unsafe must uphold the additional safety conditions themselves.
Unsafe does not disable every Rust type or borrow check, nor does it establish that the code is necessarily faulty. A sound safe abstraction contains the extra responsibility within its implementation so permitted safe-interface uses do not cause undefined behavior.
Testing evidence and complete guarantees differ
AddressSanitizer combines compiler instrumentation with a runtime library to detect executed errors such as heap, stack, and global out-of-bounds accesses, use-after-free, and selected stack-lifetime violations. A run without a report does not cover every possible program path.
Such detection has overhead and deployment conditions documented by the tool. Resource leakage is also a separate issue: Rust permits safely suppressing destruction. Failing to release a resource should not simply be equated with an invalid access that causes undefined behavior.