Skip to content
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

Clarify note stating that reading uninitialized padding is permitted #1311

Open
stevenengler opened this issue Dec 7, 2022 · 1 comment
Open
Labels
A-undefined-behavior Area: Undefined behavior

Comments

@stevenengler
Copy link

stevenengler commented Dec 7, 2022

The reference says:

  • Producing an invalid value, even in private fields and locals. "Producing" a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation. The following values are invalid (at their respective type):
    • [...]
    • An integer (i*/u*), floating point value (f*), or raw pointer obtained from uninitialized memory, or uninitialized memory in a str.

and then later:

Note: Uninitialized memory is also implicitly invalid for any type that has a restricted set of valid values. In other words, the only cases in which reading uninitialized memory is permitted are inside unions and in "padding" (the gaps between the fields/elements of a type).

What would be an example of reading uninitialized padding memory? Does this mean that reading uninitialized padding memory is an exception to the above rule (I'm guessing not, but I don't know how to interpret this note otherwise)? Would ptr::read::<u8>(ptr_to_padding) be considered "permitted"? Or does it only mean that ptr::read::<MaybeUninit<u8>>(ptr_to_padding) is "permitted"?

I think this note is unclear and should be reworded. The second sentence also starts with "In other words ...", but these two sentences seem like completely different ideas.

@stevenengler stevenengler changed the title Clarify note stating that reading unintialized padding is permitted Clarify note stating that reading uninitialized padding is permitted Dec 7, 2022
@StripedMonkey
Copy link

As far as I know this is in reference to the fact that copying/moving a struct may/will(?) read and copy the padding in the process of moving said struct despite the padding being uninitialized.

@ehuss ehuss added the A-undefined-behavior Area: Undefined behavior label Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-undefined-behavior Area: Undefined behavior
Projects
None yet
Development

No branches or pull requests

3 participants