Numeric comparison in JavaScript returns an incorrect result

[LesserGiraffe]

Description

Strict equality (===) with numbers returns an incorrect result when calling another function.

Steps to Reproduce

Run the following code:

import org.mozilla.javascript.Context;
import org.mozilla.javascript.Scriptable;

public class Main {
  public static void main(String[] args) {
    String script = """
      function funcA(a) { }

      function funcB(a) {
        if (a === 0) {
          java.lang.System.out.println('true  ' + a);
        } else {
          java.lang.System.out.println('false  ' + a);
        }
        funcA(a);
      }

      (function funcC() {
        funcB(0);
      })();
    """;

    try (Context cx = Context.enter()) {
      Scriptable scope = cx.initStandardObjects();
      cx.evaluateString(scope, script, "example", 1, null);
    }
  }
}

Expected Output

true 0

Actual Output

false 0

Environment

JDK: openJDK 21
Rhino: 1.9.1
OS: Windows 11

Additional Notes

• If funcA(a) is not called, the comparison works correctly.
• If cx.setOptimizationLevel(-1) is called to run in interpreter mode, the comparison works correctly.
• If the comparison in the if statement is written as 0 === a instead, the comparison works correctly.

[gbrail]

That is indeed very strange. We'll have to look at it. Thanks!

…

On Sat, May 16, 2026 at 11:25 PM SeaPanda ***@***.***> wrote: *LesserGiraffe* created an issue (mozilla/rhino#2407) <#2407> Description Strict equality (===) with numbers returns an incorrect result when calling another function. Steps to Reproduce Run the following code: import org.mozilla.javascript.Context;import org.mozilla.javascript.Scriptable; public class Main { public static void main(String[] args) { String script = """ function funcA(a) { } function funcB(a) { if (a === 0) { java.lang.System.out.println('true ' + a); } else { java.lang.System.out.println('false ' + a); } funcA(a); } (function funcC() { funcB(0); })(); """; try (Context cx = Context.enter()) { Scriptable scope = cx.initStandardObjects(); cx.evaluateString(scope, script, "example", 1, null); } } } Expected Output true 0 Actual Output false 0 Environment JDK: openJDK 21 Rhino: 1.9.1 OS: Windows 11 Additional Notes - If funcA(a) is not called, the comparison works correctly. - If cx.setOptimizationLevel(-1) is called to run in interpreter mode, the comparison works correctly. - If the comparison in the if statement is written as 0 === a instead, the comparison works correctly. — Reply to this email directly, view it on GitHub <#2407>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I22WXAZJEGF4B2IE22L43FLNZAVCNFSM6AAAAACZBEQ6RKVHI2DSMVQWIX3LMV43ASLTON2WKOZUGQ3DENJRG43DEMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gbrail]

FWIW: This happens in compiled mode when the "optimization level" is 9. The script misbehaves all the way back to Rhino 1.7.7.2, and I didn't try and look farther back.

This happens more often since 1.8.0 when we got rid of the "optimization level" in favor of the single boolean flag. But the bug is very old and it is related to the extra optimizations that used to be optional!

[gbrail]

And TBH some of those optional optimizations, as I recall, didn't always add value, so we could easily look at those!

[aardvark179]

So, I think it would be worth looking at the compilation pipeline as a whole. At the moment we have different numeric behaviour on compiled and interpreted modes (double -> Double versus Integer or double -> Double), and both the interpreter and the byte code compiler have a number of things that force both to jump through hoops different hoops to make things work, and that's partly because both have to go from our current IR to the final result in a single step.

Also our current IR is kind of painful.

I think it might be time to take a step back and work out a consistent model we want for things like numeric type promotion, work out a new IR (probably based round basic blocks and a control flow graph) that can fit that model and would be good for feeding both an interpreter and a class compiler, work out how to slot that into our current compilation pipeline and how we might move from our current IR to a set of steps that go from an AST to this new IR.

I don't want to dive into this too heavily yet. I know a couple of people have done some prototyping of a new IR, and @jimmyhmiller and @camnwalter did some excellent work that I'd really like to see land here first because I think it will force us to think about some stuff that is common to all compilation pipelines.