-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite docs for std::ptr
(Take #2)
#51016
Closed
Closed
Changes from 7 commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
85f97e5
Rewrite docs for `std::ptr`
ecstatic-morse ac53367
Mention alignment in top-level docs
eecae1d
Fix failing doctests
ecstatic-morse de165bb
Fix unused variable warning in doctest
ecstatic-morse 9e93c6b
Update docs for `swap_nonoverlapping`
ecstatic-morse 29c8358
Reword module level docs re: alignment
ecstatic-morse 086e1e4
Fix off-by-one error when specifying a valid range
ecstatic-morse d31eb2a
Remove definiton of valid pointer
ecstatic-morse af2a716
Redefine range validity
ecstatic-morse 2031652
Incorporate RalfJung's suggestions
ecstatic-morse 0ff407e
You can't make an omlette without breaking a few links
ecstatic-morse 5b6a3eb
Add a list of known facts re: validity
ecstatic-morse 46407ed
Resolve null/ZST conflict correctly (whoops)
ecstatic-morse File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The part after "in other words" says way more than the the first part! Also, Why is "
src
must be valid" and "src.offset(count-1)
" split into two conditions? I see one condition here, which is "src.offset(i)
must be valid for readingsize_of::<T>()
bytes for0 <= i < count
", or, equivalently, "src
must be valid for readingsize_of::<T>() * count
bytes".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I now see in your comments in the thread that you argue it would otherwise violate aliasing rules. That seems plausible but unnecessarily contorted for a definition.
Given that validity has to be defined for a size anyway, I'd just change this to require validity of the entire affected memory range at once (i.e. length
size_of::<T>() * count
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I got a bit to clever here :) I was trying to rely exclusively on the definition of validity to define invariants over arrays as well as single accesses. The notion of a "single, live allocation" doesn't appear anywhere in the reference to my knowledge, which is why it went in "in other words".
As I note in my later comment, I think that making pointer validity a function of access size overcomplicates things a bit, and that the type of the pointer should fully specify the number of bytes being accessed when reading or writing.
From this point of view, your
src.offset(i)
for alli
in0..count
works formulation nicely, although it still references offset, which is maybe a bit opaque.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my eyes, making it depend on the whole type makes things more complicated. With your proposal, validity is a function of the pointer and its type, and you should say so clearly ("A pointer pointing to type
T
is valid ..."). A type contains much more information than just a size! With my proposal, it is crystal clear that the size of the only part that actually matters ("A pointer is valid for an access of sizen
..."). Notice that I use "pointer" here as a run-time concept; pointers themselves (as in, just the raw address in memory -- or whatever abstract representation of pointers you want to think of) are intrinsically untyped. So either way you need to add some extra information to define validity; the question is only if you restrict that to what is actually necessary (the size) or if you add a whole lot of other irrelevant information as well (the type).Plus, for functions where the type alone does not suffice, we don't have to do awkward things like use
.offset
in our definition and rely on that function to be undefined when crossing allocation boundaries.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean I would need to qualify that, for example,
ptr::read
requires that its argument be valid for a read of at leastsize_of::<T>()
bytes? This is what I meant by overcomplicates, not that the concept itself wasn't necessary, but that stating it everywhere would be redundant.Simply declaring that when the size of an access for
*const T
is not explicitly stated, we mean valid forsize_of::<T>()
bytes would work.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this!