Bug 23559

Summary: (10 != null), not even on 64-bit.
Product: WebKit Reporter: Gavin Barraclough <barraclough>
Component: JavaScriptCoreAssignee: Gavin Barraclough <barraclough>
Severity: Normal    
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Description Flags
The patch darin: review+

Description Gavin Barraclough 2009-01-26 16:49:09 PST
Specifically, this is a 64-bit JIT bug, and is breaking v8-crypto.
Comment 1 Gavin Barraclough 2009-01-26 16:57:17 PST
Created attachment 27054 [details]
The patch
Comment 2 Darin Adler 2009-01-26 17:01:16 PST
Comment on attachment 27054 [details]
The patch


Is this already covered by a regression test?
Comment 3 Gavin Barraclough 2009-01-26 17:17:55 PST
(In reply to comment #2)
> (From update of attachment 27054 [details] [review])
> Is this already covered by a regression test?


No, it's not covered, I was thinking about that.  I could add a regression test to test specifically whether (10 == null), but in a way that feels a little restrictive, and implementation dependent.  (this bug occurs since the encoding we happen to use for null happens to be 10, and that we were incorrectly cropping out the high 32-bits).  This test would become redundant as soon as we changed the encoding we use for null.

At minimum I think I should add a test the checks that null != N, where -255 <= N <= 255, (except, I'm guessing, for zero).  But I'd like to try to think of something that feels a little more generic.  We should probably also have similar tests for the boolean values, and possibly also for cases where the low 32bits of a double precision number will match an integer value.

I'll think a bit more & submit something.


Sending        JavaScriptCore/ChangeLog
Sending        JavaScriptCore/jit/JIT.cpp
Transmitting file data ..
Committed revision 40279.