| Summary: | Incorrect behaviour of jneq_null in the interpreter | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Oliver Hunt <oliver> | ||||
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | barraclough, eric | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | PC | ||||||
| OS: | OS X 10.5 | ||||||
| Attachments: |
|
||||||
Created attachment 43894 [details]
Patch
I'm sure Oliver will chase down the right people, but just in case. Comment on attachment 43894 [details]
Patch
I would be happy to r+ this, as it sounds simple. Except w/o test result updates, it's difficult for me to see how it's correct.
(In reply to comment #3) > (From update of attachment 43894 [details]) > I would be happy to r+ this, as it sounds simple. Except w/o test result > updates, it's difficult for me to see how it's correct. The interpreter currently fails tests due to this -- the issue is that the existing logic will always short circuit on the isUndefinedOrNull for any cell -- eg. the type where we actually have to do the masquerade check. Yeah, I think my confusion is just that I was surprised there were no test expectation changes in your patch. That's all. |
The interpreters implementation of op_jneq_null is incorrect when the value being compared is set to masquerade as undefined. The result is that if (document.all == null) { alert("PASS") } else { alert("FAIL") } Will fail.