geometry: Propagate NaN in min/max operations#22585
Merged
Conversation
wpt-pr-bot
approved these changes
Apr 1, 2020
Collaborator
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
Currently in some geometry classes we are using std::min() and
std::max() over numbers specified in IDL as "unrestricted double",
meaning they could take the special value NaN. These STL helpers
internally use the < operator, as in
std::min(a, b) = a < b ? a : b.
However, the IEEE 794 < operator always returns false when _either_
operand is NaN, so the result of min(0, NaN) and min(NaN, 0) could,
confusingly, be different.
This is difference is in fact visible through JavaScript. For instance,
new DOMQuad({ x: NaN }, { x: 0 }, { x: 0 }, { x: 0 }).getBounds().x
gives NaN, but
new DOMQuad({ x: 0 }, { x: 0 }, { x: 0 }, { x: NaN }).getBounds().x
gives 0.
A similar problem is present for DOMRect/DOMRectReadOnly as well.
This CL implements [1], which is to adopt semantics similar to
JavaScript's Math.min() and Math.max(), which propagates NaN from either
operand. This also aligns our behavior with WebKit.
[1]: w3c/fxtf-drafts#395
Fixed: 1066499
Change-Id: Id9a4282fa00dafcfe9c5616643efbe2eaace411e
84e7374 to
ad2cab7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Currently in some geometry classes we are using std::min() and
std::max() over numbers specified in IDL as "unrestricted double",
meaning they could take the special value NaN. These STL helpers
internally use the < operator, as in
However, the IEEE 794 < operator always returns false when either
operand is NaN, so the result of min(0, NaN) and min(NaN, 0) could,
confusingly, be different.
This is difference is in fact visible through JavaScript. For instance,
gives NaN, but
gives 0.
A similar problem is present for DOMRect/DOMRectReadOnly as well.
This CL implements 1, which is to adopt semantics similar to
JavaScript's Math.min() and Math.max(), which propagates NaN from either
operand. This also aligns our behavior with WebKit.
Fixed: 1066499
Change-Id: Id9a4282fa00dafcfe9c5616643efbe2eaace411e
Reviewed-on: https://chromium-review.googlesource.com/2129889
WPT-Export-Revision: c842d3fd36b1743a5979b36df378ecdd1d19a6c6