You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The semantics is, crucially, "monotone" with respect to initialization: replacing an Uninit byte in memory by any other byte can never introduce UB, it can only make program behavior "more defined". Should we have the same with respect to provenance, i.e., should replacing a Raw byte by a Ptr byte (with the same data value) with arbitrary provenance only make the program more defined? Due to all the constraints on how encode and decode relate, this is equivalent to asking: should ptr2int transmutation implicitly strip provenance (instead of being UB, like it is now)?
The semantics is, crucially, "monotone" with respect to initialization: replacing an
Uninit
byte in memory by any other byte can never introduce UB, it can only make program behavior "more defined". Should we have the same with respect to provenance, i.e., should replacing aRaw
byte by aPtr
byte (with the same data value) with arbitrary provenance only make the program more defined? Due to all the constraints on howencode
anddecode
relate, this is equivalent to asking: should ptr2int transmutation implicitly strip provenance (instead of being UB, like it is now)?I do not have a set opinion on this. Also see this Zulip discussion. rust-lang/unsafe-code-guidelines#286 is the UCG issue; here I am just tracking the MiniRust consequences of that decision.
The text was updated successfully, but these errors were encountered: