Clarify one-past-the-end pointer validity#154370
Clarify one-past-the-end pointer validity#154370justanotheranonymoususer wants to merge 1 commit intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
r? @scottmcm rustbot has assigned @scottmcm. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| /// | ||
| /// * If the computed offset is non-zero, then `self` must be [derived from][crate::ptr#provenance] a pointer to some | ||
| /// [allocation], and the entire memory range between `self` and the result must be in | ||
| /// [allocation], and the entire memory range between `self` and the result (not including result) must be in |
There was a problem hiding this comment.
for sub the self argument is after the result, so this would need to be not including self, right? also "memory range from the result to self (exclusive)" reads a bit more fluently to me.
There was a problem hiding this comment.
For sub, not sure if the note is relevant because the pointer isn't moving forward. If non-zero and non-wraparound, you can't end up in the one-past-the-end situation anyway.
For "not including result" vs "exclusive", for me as not a native speaker, my version is clearer, but I can change. Let me know.
4 participants
It's documented that
vec.as_ptr().add(vec.len())is safe, but the main safety condition wasn't clear enough.