-
Notifications
You must be signed in to change notification settings - Fork 28
#246 [Coding Guideline]: Do not access memory using a pointer with an incorrect provenance #264
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
base: main
Are you sure you want to change the base?
#246 [Coding Guideline]: Do not access memory using a pointer with an incorrect provenance #264
Conversation
✅ Deploy Preview for scrc-coding-guidelines ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@manhatsu This is going to continue to be a rule about provenance so it should definitely have provenance in the title, otherwise I won't be able to find it. For now I suggest the title be "Do not access memory using a pointer with incorrect provenance" |
Updated guidelines on pointer comparisons and memory access to clarify the importance of provenance and the implications of comparing pointers from different allocations.
|
@rcseacord It was my lack of understanding. I changed the title as you suggested. |
added new noncompliant / compliant solution
| Do not access memory using a pointer with an incorrect provenance. | ||
| Pointers, including values of reference type, have two components. | ||
| The pointer’s address identifies the memory location where the pointer is currently pointing. | ||
| The pointer’s provenance determines where and when the pointer is allowed to access memory. |
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 provenance also determines if the pointer is allowed to mutate the memory. See also the std docs for this: https://doc.rust-lang.org/std/ptr/index.html#provenance
This should maybe also be taken into account below when discussing when a memory access is UB.
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.
resolved.
| - Outcomes of pointer arithmetic across allocation boundaries | ||
|
|
||
| This rule ignores any metadata that may come with wide pointers; | ||
| it only pertains to thin pointers and the data part of a wide pointer. |
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.
| it only pertains to thin pointers and the data part of a wide pointer. | |
| it only pertains to thin pointers and the address part of a wide pointer. |
The additional data of a wide pointer is often called metadata (See the unstable function for reading it: https://doc.rust-lang.org/std/ptr/fn.metadata.html or the previous sentence). So calling the address "data" is confusing.
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.
resolved
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.
Do you want to link to unstable docs? If yes it may be better to link to https://doc.rust-lang.org/std/ptr/trait.Pointee.html#pointer-metadata as here the current kinds of metadata are explained?
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.
@inkreasing OK, i added this link. do you see any other problems with this or does it look ready to merge?
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.
resolved (again)
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.
@rcseacord Oh sorry i am not in any position to decide wether this is ready to be merged. This was basically a drive-by review. Will make that clear from the beginning next time.
link to unstable docs as here the current kinds of metadata are explained.
Closes #246.