diff options
| author | bors <bors@rust-lang.org> | 2022-05-31 12:14:51 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2022-05-31 12:14:51 +0000 |
| commit | 16a0d03698bfc9f93250490797f9a1a870f8bcfe (patch) | |
| tree | cdf5c0c82d1e2c501badb5b8e1cb15d763964dc1 /compiler/rustc_codegen_llvm/src/llvm_util.rs | |
| parent | dcbd5f5134e396353207f1f79e50794b83cee7d2 (diff) | |
| parent | 8ef2dd70e6dc90a8895ca5000a2868e411ba34b7 (diff) | |
| download | rust-16a0d03698bfc9f93250490797f9a1a870f8bcfe.tar.gz rust-16a0d03698bfc9f93250490797f9a1a870f8bcfe.zip | |
Auto merge of #97521 - SkiFire13:clarify-vec-as-ptr, r=Dylan-DPC
Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation Currently the documentation says they return a pointer to the vector's buffer, which has the implied precondition that the vector allocated some memory. However `Vec`'s documentation also specifies that it won't always allocate, so it's unclear whether the pointer returned is valid in that case. Of course you won't be able to read/write actual bytes to/from it since the capacity is 0, but there's an exception: zero sized read/writes. They are still valid as long as the pointer is not null and the memory it points to wasn't deallocated, but `Vec::as_ptr` and `Vec::as_mut_ptr` don't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads since `Vec` is implemented to hold a dangling pointer in those cases, which is neither null nor was deallocated.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src/llvm_util.rs')
0 files changed, 0 insertions, 0 deletions
