#235 [Coding Guideline]: Do not read uninitialized memory of any non-union type as a typed value#240
#235 [Coding Guideline]: Do not read uninitialized memory of any non-union type as a typed value#240manhatsu wants to merge 29 commits intorustfoundation:mainfrom
Conversation
✅ Deploy Preview for scrc-coding-guidelines ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
I've made some improvement suggestions in a PR here: manhatsu#1 |
Thank you very much. Merged to this branch |
|
Hey @manhatsu 👋 it looks like from the CI that a new tag needs to be added. Could you follow what @rcseacord did in this PR to add the |
manhatsu
force-pushed
the
doc/no-uninit-value
branch
from
d3b29b5 to
57f303a
Compare
PLeVasseur
force-pushed
the
doc/no-uninit-value
branch
from
57f303a to
4b8cbc7
Compare
PLeVasseur
left a comment
PLeVasseur
left a comment
There was a problem hiding this comment.
Hi @manhatsu -- thank you for contributing. Please see the comment I left on how to generate a template.
PLeVasseur
added
chapter: values
coding guideline
There was a problem hiding this comment.
What @inkreasing says is correct. This description is insufficient to reflect the restrictions imposed by MIRI here:
Note this is not UB before line 15.
Bytes remain uninit until written. You may not read uninitialized bytes as any initialized type, period, not even if "all" bitpatterns are considered valid, because uninit is the 257th bitpattern for a byte, effectively: 0xUU. By contrast, u8 is 0x00 through 0xFF, inclusive. We use MaybeUninit<u8> to indicate the final state is possible, and it is valid to read that value (well, from any allocation that has a byte in it, at least).
manhatsu
force-pushed
the
doc/no-uninit-value
branch
from
9b81ff4 to
0e2776c
Compare
|
Sidenote: this probably should be part of the Unsafety chapter. Anything dealing with upholding validity invariants in |
I created an issue #241 that discusses this. See what you think. Anyway, we should probably have this discussion there. |
PLeVasseur
force-pushed
the
doc/no-uninit-value
branch
from
dcb19bf to
8d4a655
Compare
|
Hi @manhatsu, @rcseacord -- please see this PR: #288 Please simply replace the current commits on your feature branch with that single commit on the above PR. That way we can keep the review history on this PR. |
|
@felix91gr I might be coming around to your view that union should be split out into a different rule. |
manhatsu
force-pushed
the
doc/no-uninit-value
branch
from
20d6c35 to
2ade1b3
Compare
spelling
Co-authored-by: increasing <[email protected]>
Clarified guideline on reading uninitialized memory, specifying non-union types and adding citations for better understanding.
Add miri directives and normalize citations/bibliography entries so the guideline builds cleanly.
PLeVasseur
force-pushed
the
doc/no-uninit-value
branch
from
802b444 to
6ce3ddb
Compare
Allow warnings for UB demonstrations and prefix unused locals in the uninitialized-memory guideline to keep example tests clean.
Co-authored-by: increasing <[email protected]>
Clarify the explanation of undefined behavior in the noncompliant example.
felix91gr
left a comment
felix91gr
left a comment
There was a problem hiding this comment.
Sorry I took so long. I hope this helps.
I think the examples are pretty good in general; I'm mostly suggesting improvements to the presentation plus a couple of details here and there.
| :tags: undefined-behavior, unsafe | ||
|
|
||
| Do not read uninitialized memory of any non-union type as a typed value :cite:`gui_uyp3mCj77FS8:RUSTNOMICON-UNINIT`. | ||
| This is sometimes referred to as *transmuting* or *read-at-type*. |
There was a problem hiding this comment.
What would you say is the difference between this and std::mem::transmute? Maybe we ought to point out that this is not the same, since transmute is quite the famous unsafe function.
There was a problem hiding this comment.
@felix91gr I got this information from @workingjubilee
I believe these things are roughly equivalent in the context they are used here in that they are all typed reads.
| * ``assume_init_drop`` | ||
| * ``assume_init_mut`` | ||
| * ``assume_init_read`` | ||
| * ``assume_init_ref`` | ||
| * ``array_assume_init`` |
There was a problem hiding this comment.
Perhaps these APIs should also get linked here, much like assume_init is above
There was a problem hiding this comment.
added some links, now we'll see if it builds.
| :status: draft | ||
|
|
||
| This noncompliant example creates a reference from uninitialized memory. | ||
| Creating a reference from arbitrary or uninitialized bytes is undefined behavior :cite:`gui_uyp3mCj77FS8:RUST-REF-BEHAVIOR`. |
There was a problem hiding this comment.
I'm not sure this is entirely correct. A reference could be created from arbitrary bytes, e.g.
let bytes = 999u32.to_be_bytes();
let nine_nine_nine = u32::from_be_bytes(bytes);There was a problem hiding this comment.
I can't find this any longer.
There was a problem hiding this comment.
What do you mean? :O
You can't find the sentence that says "Creating a reference from arbitrary or uninitialized bytes is undefined behavior"?
It should be at line 119
Co-authored-by: Félix Fischer <[email protected]>
Removed redundant explanations about undefined behavior for uninitialized memory and bool types.
Co-authored-by: Félix Fischer <[email protected]>
Co-authored-by: Félix Fischer <[email protected]>
Co-authored-by: Félix Fischer <[email protected]>
Co-authored-by: Félix Fischer <[email protected]>
Co-authored-by: Félix Fischer <[email protected]>
Co-authored-by: Félix Fischer <[email protected]>
felix91gr
changed the title
|
Upkeep: I've updated the title of the PR so that it may be the same as the title of the guideline |
6 participants
Closes #235.