nomicon
nomicon copied to clipboard
rust-lang
significantly cleanup and flesh out page on UB
Extremely Rough Note before I wander off: I feel like I want to define a concrete notion of two different ways a type can occupy memory to address how unions/enums have a strange relationship with uninit memory.
Perhaps it's sufficient to just appeal to size vs "actual" memory? I believe we do not actually require/guarantee that e.g. moving an Option<u32> moves the memory footprint of the Some variant (ignoring the specific ongoing discussion of ptr::copy and padding which is weird).
Like it should be fine for us to check/know that the variant is None and just copy the tag. Too dizzy to think and need to bounce.
I believe we do not actually require/guarantee that e.g. moving an Option
moves the memory footprint of the Some variant (ignoring the specific ongoing discussion of ptr::copy and padding which is weird).
Indeed, padding does not have to be copied. Some UCG resources on this:
- https://github.com/rust-lang/unsafe-code-guidelines/issues/183
- https://github.com/rust-lang/unsafe-code-guidelines/pull/195
- My value domain proposal has a notion of "typed copy" that both handles "invalid data is UB" and "padding does not have to be copied".
Should there be a mention that null vtable pointers for even trait object raw pointers (And not just references which I believe could be understood from https://github.com/rust-lang-nursery/nomicon/pull/149/files#diff-9f9e3daa6dcba4f53211916eb094e123R37) are UB (Which iirc they are. Like in https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=82583ed18f9d0891adb54e5403269dec . https://github.com/rust-lang/rfcs/issues/433#issuecomment-345497470 says it is).
@nico-abram Agreed -- if we decide that we really want this non-NULL property, we should add it here. But I don't think this is clear-cut yet.
Fair. In my mind this is still a rustc bug but I guess many won't agree. ;)