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
[Assignment] has the effect of first dropping the value at the assigned place, unless the place is an uninitialized local variable or an uninitialized field of a local variable.
To me, this wording "dropping the value" suggests that it produces the value at the assigned place, and therefore if the place is uninitialized and not one of the called out cases, then undefined behavior occurs. However, rust-lang/unsafe-code-guidelines#317 and Miri seem to disagree, accepting code like this:
fnmain(){letmut x = std::mem::MaybeUninit::<f64>::uninit();unsafe{*x.as_mut_ptr() = 1.0;}}
(Note in particular that f64 has no destructor code, and cannot because it is Copy. Obviously if it did, then this would be at least library UB.)
The page Destructors says that executing a destructor consists of invoking a certain set of Drop::drop() functions, which take &mut references (and thus impose whatever validity requirements those have), but it doesn't clearly, definitively specify that there are no other requirements as might be intuitively assumed, such as those of “producing” the value that is about to be dropped, or creating an &mut to the whole place. That, together with the text on assignment referring to “dropping the value” without further explanation, makes the situation less than clear.
Solution
I think that the Reference should:
Specify more obviously exhaustively what operations “a destructor” consists of, and that it is an operation that is done to a place.
Discuss the automatic destruction of variables and temporaries in a separate paragraph from introducing destructors in general.
Explicitly call out the cases where dropping an uninitialized place is or is not UB, since assigning to an uninitialized place is (in my experience) an easy mistake to make when trying to write data to a slice of uninitialized memory, and it would be nice to have a clear citation for “this is UB” vs. “this is not UB (even if it is bad style)”.
Perhaps avoid speaking anywhere of “dropping the value”, but in any case, make sure that every place which talks of invoking a destructor does so in a precise way.
I'm assuming based on the UCG issue that this is not an open UCG/T-opsem question, and the chosen behavior merely needs to be documented, hence why I am filing this issue against the Reference.
I would be interested in helping write the needed text, if there is agreement that these changes are appropriate.
The text was updated successfully, but these errors were encountered:
Problem
The reference currently says:
To me, this wording "dropping the value" suggests that it produces the value at the assigned place, and therefore if the place is uninitialized and not one of the called out cases, then undefined behavior occurs. However, rust-lang/unsafe-code-guidelines#317 and Miri seem to disagree, accepting code like this:
(Note in particular that
f64
has no destructor code, and cannot because it isCopy
. Obviously if it did, then this would be at least library UB.)The page Destructors says that executing a destructor consists of invoking a certain set of
Drop::drop()
functions, which take&mut
references (and thus impose whatever validity requirements those have), but it doesn't clearly, definitively specify that there are no other requirements as might be intuitively assumed, such as those of “producing” the value that is about to be dropped, or creating an&mut
to the whole place. That, together with the text on assignment referring to “dropping the value” without further explanation, makes the situation less than clear.Solution
I think that the Reference should:
I'm assuming based on the UCG issue that this is not an open UCG/T-opsem question, and the chosen behavior merely needs to be documented, hence why I am filing this issue against the Reference.
I would be interested in helping write the needed text, if there is agreement that these changes are appropriate.
The text was updated successfully, but these errors were encountered: