[Webkit-unassigned] [Bug 145992] Strict Equality on objects should only check that one of the two sides is an object.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Jun 24 10:43:07 PDT 2015
https://bugs.webkit.org/show_bug.cgi?id=145992
Mark Lam <mark.lam at apple.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #255486|review? |review+
Flags| |
--- Comment #31 from Mark Lam <mark.lam at apple.com> ---
Comment on attachment 255486
--> https://bugs.webkit.org/attachment.cgi?id=255486
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=255486&action=review
r=me with fixes.
> Source/JavaScriptCore/ChangeLog:9
> + comparison between the two values (although in the 32-bit case we must also check
missing âthatâ: ⦠check *that* the other ...
> Source/JavaScriptCore/dfg/DFGSpeculativeJIT32_64.cpp:1235
> + if (taken == nextBlock()) {
> + branch32(MacroAssembler::NotEqual, op1GPR, op2GPR, notTaken);
> + jump(taken);
> + } else {
> + branch32(MacroAssembler::Equal, op1GPR, op2GPR, taken);
> + jump(notTaken);
> + }
This is so much cleaner and easier to read and to reason about. Is there a reason why you wouldnât do it this way for the 64-bit version as well?
> Source/JavaScriptCore/jsc.cpp:888
> + // Need to cast to int64_t so bitwise_cast will play along.
> + int64_t asNumber = reinterpret_cast<uint64_t>(value.asCell());
You are right that a reinterpret_cast wonât sign extend. So, my previous suggestion to use uint64_t is not really necessary (though uint64_t does feel warm and fuzzier than int64_t). That said, youâre casting to uint64_t here, but the result type is still int64_t. Ditto for comment.
> Source/JavaScriptCore/tests/stress/equality-type-checking.js:3
> + * when determining equality via pointer comparision.
typo: comparison.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150624/76780dd9/attachment-0001.html>
More information about the webkit-unassigned
mailing list