ordered_float:NotNan may contain NaN after panic in assignment operators #514
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After using an assignment operators such as
NotNan::add_assign
,NotNan::mul_assign
, etc., it was possible for the resultingNotNan
value to contain aNaN
. This could cause undefined behavior in safe code, because the safeNotNan::cmp
method contains internal unsafe code that assumes the value is neverNaN
. (It could also cause undefined behavior in third-party unsafe code that makes the same assumption, as well as logic errors in safe code.)This was mitigated starting in version 0.4.0, by panicking if the assigned value is
NaN
. However, in affected versions from 0.4.0 onward, code that uses theNotNan
value during unwinding, or that continues after catching the panic, could still observe the invalid value and trigger undefined behavior.The flaw is fully corrected in versions 1.1.1 and 2.0.1, by ensuring that the assignment operators panic without modifying the operand, if the result would be
NaN
.Fix details:
reem/rust-ordered-float#20
reem/rust-ordered-float#71