[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