Clarify the guarantees of Vec::as_ptr and Vec::as_mut_ptr when there's no allocation#97521
Conversation
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ rollup |
|
📌 Commit 8ef2dd7 has been approved by |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (16a0d03): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
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, butVec::as_ptrandVec::as_mut_ptrdon't specify that's not the case. This PR thus specifies they are actually valid for zero sized reads sinceVecis implemented to hold a dangling pointer in those cases, which is neither null nor was deallocated.