Expression boolean operators keep only the low 32 bits of a long operand: (1 << 32) ? 1 : 0 is 0

Lucene expressions compile a formula to bytecode, giving every sub-expression a JVM type: int, long or double. The bitwise and shift operators and hex/octal literals are 64-bit longs (1 << 32 is 4294967296), but the four boolean operators !, &&, || and ?: request their operand as an int and narrow a long with l2i, which keeps only the low 32 bits. So a non-zero long whose low 32 bits are zero counts as false: (1 << 32) ? 1 : 0 and 0x100000000 ? 1 : 0 are 0, !(1 << 32) is 1, while (1 << 32) != 0 is 1 and the same number written in decimal is true.

The practical case is a flag test of bits 32 to 63 of a long doc-values field: (flags & 0x100000000) ? 10 : 1 returns 1 and !(flags & 0x100000000) returns 1 for a document with bit 32 set, so the condition is false for every document, and documents with the bit set get the wrong value in scores, sort keys and expression filters, with no error. Bits 0 to 31 and the comparison forms (e) != 0 and (e) == 0 are correct.

The int operand is in the module's first patch (LUCENE-5207, 2013): all 122 lucene-expressions releases from 4.6.0 to 10.6.0 fail, and so does main. Not fixed upstream. Fix: evaluate the operand as a long and compare it with 0L, which changes nothing for double operands.

1. The code generator is type-directed. Each visitor of JavascriptCompiler pushes the type its parent expects onto typeStack, and each child converts its result to typeStack.peek() with gen.conversion(...).
2. The boolean operators ask for an int. ! pushes TypeKind.INT for its operand (visitUnary, JavascriptCompiler.java:518) and branches with ifeq (:521); && (:694, ifeq at :696, :698), || (:714, ifne at :716, :718) and the ?: condition (:734, ifeq at :737) do the same.
3. Bitwise and shift results are longs, narrowed to the expected type. pushShift and pushBitwise compute in long (:751-757), and pushBinaryOp ends with gen.conversion(returnType, typeStack.peek()) (:773): long to int is l2i. ~ does the same (:534). A hex or octal literal goes through pushLong, which pushes (int) i in an int position (:796).
4. l2i and (int) keep the low 32 bits. 4294967296 = 2^32 has only bit 32 set, so it becomes 0 and ifeq takes the false branch. In general a non-zero long operand is false exactly when its low 32 bits are zero (checked with an SMT solver); a single-bit test (x & (1 << k)) is false for every x when 32 <= k <= 62 (solver) and for bit 63 (executed: (1 << 63) ? 1 : 0 is 0).
5. Doubles of magnitude 1 or more are not affected. A decimal literal (:438-439), a variable (:503), a function result (:494) or arithmetic is a double, narrowed with d2i, which saturates: 4294967296.0 becomes Integer.MAX_VALUE, still non-zero. That is why 4294967296 ? 1 : 0 and ((1 << 32) + 0) ? 1 : 0 are 1. (d2i also makes a fraction false; see the fractions note below.) Comparisons evaluate both sides as doubles (:650): a long result reaches (e) != 0 through l2d, which is non-zero for every non-zero long.

Requesting the four operands as long and comparing them with 0L makes the repro and every row below correct, so the narrowing is the whole cause.

(1 << 32) || 0 is 0 as well (expected 1). Over an indexed NumericDocValuesField with flags = 4294967297, (flags & 0x100000000) ? 10 : 1 gives 1 instead of 10 and !(flags & 0x100000000) gives 1 instead of 0.

The same int operand also makes a fractional double false, through d2i: with x = 0.5, x ? 1 : 0 is 0 while x != 0 is 1. No document states a truth rule for fractions either way, so that case was judged a documentation question rather than a code bug. Fix B below leaves it unchanged; fix A changes it too.

• Silent wrong results. The expression returns a number and nothing fails. Scores (getDoubleValuesSource in a FunctionScoreQuery), sort keys (getSortField), rescoring and expression-based filters (FunctionMatchQuery over the values source) take the false branch even where the tested bit is set.
• Who is exposed. Users of lucene-expressions at default settings, any index size, assertions on or off, who apply a boolean operator directly to a bitwise or shift result or a hex/octal literal that is non-zero with all-zero low 32 bits. In practice: a test of one of bits 32 to 63 of a long bitmask field, written (flags & MASK) ? a : b or !(flags & MASK). Such a single-bit test is false for every document.
• Expressions are the suggested tool for bitwise flag tests. On #3534 (an open feature request for bitwise filtering on numeric fields), gsmiller suggested in 2024 using expressions over a numeric doc-values field "since the compiler supports bitwise operations"; the comment names no particular form (?:, ! or a comparison). Downstream users write flag tests in expressions too (elastic/elasticsearch#26272, with small values).
• Filter effect, executed. A FunctionMatchQuery with predicate v != 0 over 5 documents with flags = 0, 1, 2^32, 2^32 | 1 and 2^40: !(flags & 0x100000000) matches 5 of 5 instead of 3, (flags & 0x100000000) ? 1 : 0 matches 0 instead of 2, and the == 0 / != 0 forms match 3 and 2, correctly (main with assertions on and off, 10.5.2).
• Not affected. Bits 0 to 31, the comparison forms (e) != 0 and (e) == 0, a decimal literal, variable or arithmetic result of magnitude 1 or more used directly as the operand (a fraction is the separate fractions case above), and the index itself.
• A separate limit, not this bug. A long doc-values field reaches an expression as a double (DoubleValuesSource.fromLongField returns (double) v), so a field value above 2^53 in magnitude can lose low bits before & runs: for flags = 2^53 + 1, (flags & 1) != 0 is 0, before and after fix B. Values up to 2^53, such as every example here, are exact.
• How likely. Rare: it needs a high-bit test written without a comparison. A single high-bit test is false for every document, so a quick test shows it, and no public report was found in 13 years of releases.

The test sits in org.apache.lucene.expressions.js next to the compiler's other tests and uses only JavascriptCompiler.compile and Expression.evaluate(null), as TestJavascriptOperations does for an expression without variables. The result does not depend on the seed (it fails with DEADBEEF and 5EED1234).

LuceneTestCaseJupiter exists only on main. For the release jars, the same assertion in a class that extends org.apache.lucene.tests.util.LuceneTestCase (no @Test annotation) fails unchanged on 10.6.0, 10.5.2 and 9.12.3; the history sweep ran a main() port on every release from 4.6.0.

TestBooleanOperandHighBits > testConditionOnOneShiftedLeft32() FAILED
    java.lang.AssertionError: expected:<1.0> but was:<0.0>
        at __randomizedtesting.SeedChain.seed([DEADBEEF:FB778992B7FCCC6A:80DC09A7BA44E00D])
        at junit@4.13.2/org.junit.Assert.fail(Assert.java:89)
        at junit@4.13.2/org.junit.Assert.failNotEquals(Assert.java:835)
        at junit@4.13.2/org.junit.Assert.assertEquals(Assert.java:555)
        at junit@4.13.2/org.junit.Assert.assertEquals(Assert.java:685)
        at org.apache.lucene.expressions.js.TestBooleanOperandHighBits.testConditionOnOneShiftedLeft32(TestBooleanOperandHighBits.java:27)
4 tests completed, 1 failed   # the other 3 are LuceneTestCaseJupiter's built-in class checks

• The tests pin both halves of the conflict. Non-zero integers other than 1 are true: !2 = 0, !-1 = 0 (TestJavascriptOperations.java:178-184), -1 ? 2 : 3 = 2 (:214). The bitwise operators and hex literals are 64-bit: -15 << 62 = 4611686018427387904 (:238), -1 >>> 37 = 134217727 (:260), 0x1234ABCDEF = 78193085935 (:331). 4294967296 is a non-zero integer that the module itself produces, yet it counts as false.
• The result depends on how the number is written. 0x100000000 ? 1 : 0 = 0 but 4294967296 ? 1 : 0 = 1; (1 << 32) ? 1 : 0 = 0 but ((1 << 32) + 0) ? 1 : 0 = 1 and (1 << 32) != 0 = 1. A sub-expression bound by name through SimpleBindings.add(String, Expression) gives 1 where the same text inlined gives 0.
• The docs list the operators side by side. The package javadoc lists hex and octal literals, the bitwise operators | & ^ ~ << >> >>> and the boolean operators && || ! ?: in "an expression syntax that's based on JavaScript expressions" (package-info.java:21-28). No javadoc, CHANGES or MIGRATE entry says the boolean operators see only 32 bits.
• No recorded rationale. The int operand is in the first patch (LUCENE-5207, 2013) and survived four rewrites; no test applies a boolean operator to a long of 2^32 or more, and none of the reviewed commit messages, code comments and discussions mentions it.

The strongest case for "intended" (an independent reviewer from another model family, rated moderate): JavascriptCompiler and Expression are @lucene.experimental (JavascriptCompiler.java:111), no document defines how a number becomes a boolean, the int lowering is 13 years old, and JavaScript's own & is 32-bit, so JavaScript also takes the false branch for (flags & 0x100000000) ? a : b.

Why it fails: Lucene deliberately makes <<, & and hex literals 64-bit (its own tests), so JavaScript's 32-bit & cannot excuse the result; for (1 << 32) ? 1 : 0 and 0x100000000 ? 1 : 0 JavaScript returns 1 as well (a reference run in node 24; for the first only because JavaScript takes shift counts mod 32, so its 1 << 32 is 1), so Lucene matches neither JavaScript nor 64-bit values; experimental allows API changes, not a non-zero value that is false in one spelling and true in another; and no test, commit or discussion chose the truncation. Verdict: a code bug (every verifier, the cross-model reviews and the adjudication say real; the adjudication and the cross-model reviews with high confidence).

Two options were built and validated through gradle on 645d4fe14a20; a third is listed only to show why it is not recommended.

A helper replaces the typeStack.push(TypeKind.INT) / visit / pop sequence in visitUnary (BOOLNOT), visitBooland, visitBoolor and visitConditional; the ifeq/ifne branches stay as they are (+19/-14 in JavascriptCompiler.java). With LONG expected, bitwise and shift results and hex/octal literals arrive with all 64 bits, nested boolean results arrive as 0L/1L, and lcmp against 0L leaves 0 exactly when the operand is 0.

  private void pushTruth(ExpressionContext operand) {
    typeStack.push(TypeKind.LONG);
    visit(operand);
    typeStack.pop();
    gen.lconst_0();
    gen.lcmp();
  }

  // in each of the four visitors, for example visitConditional:
- typeStack.push(TypeKind.INT);
- visit(ctx.expression(0));
- typeStack.pop();
+ pushTruth(ctx.expression(0));
  gen.ifeq(condFalse);

Trade-offs

• Only the broken cases change. A double operand is now converted with d2l instead of d2i; both give 0 for exactly the same doubles (NaN and -1 < v < 1), so decimal literals, variables, functions and arithmetic keep their truth. Executed: 0.5 ? 1 : 0, !0.5, -0.5 ? 1 : 0, NaN, -0, 1e300 and the shift count in 1 << (0x100000000 | 2) give the same values as before.
• It leaves the fractional case as it is: 0.5 ? 1 : 0 stays 0.
• One lcmp per operand; no benchmark was run. The shift count, a separate int-typed position (pushShift, :751-753), is not touched.

What the checks validated

• Gradle, scratch worktree of 645d4fe14a20, seed DEADBEEF: the repro fails on stock and passes with fix B, assertions on and off.
• The whole :lucene:expressions:test with fix B and the repro (assertions on): 14 suites, 174 tests, 0 failures, 0 skipped (the 13 upstream suites with 170 tests, including TestJavascriptOperations and TestJavascriptCompiler, plus the repro).
• :lucene:expressions:check -x test (checkGoogleJavaFormat, ecjLintMain, ecjLintTest, forbiddenApisMain, forbiddenApisTest): passes.
• The 17-row probe (the table above) with fix B loaded: 0 rows wrong, 7 on stock.

The finder's sketch: a helper evaluates the operand with TypeKind.DOUBLE, calls Math.abs, compares with 0.0 via dcmpl (so NaN stays false) and branches with ifgt/ifle. A long operand reaches it through l2d, which is non-zero for every non-zero long.

Trade-offs

It also makes fractions true: 0.5 ? 1 : 0 goes from 0 to 1, !0.5 from 1 to 0 (NaN, -0 and 0 stay false). That would settle the fractional case as well, but it changes the results of existing expressions for 0 < |v| < 1, so it would need a CHANGES/MIGRATE note and is a policy decision for maintainers.

What the checks validated

The whole :lucene:expressions:test with fix A and the repro: 174 tests, 0 failures; the 17-row probe: 0 rows wrong. The format and lint checks were not run for A.

Convert long to int through double in pushBinaryOp and ~, and push (int)(double) for literals.

Trade-offs

It fixes the repro and passes the 170 tests, but it also changes long-typed shift counts of 2^31 or more: 1 << (0x100000000 | 2) goes from 4.0 to about -9.22e18, which no upstream test covers. A and B leave it at 4.0.

Method: semi-formal (a hunt unit, the expressions compiler).

• The finder, an AI tool, wrote an exact model of JavascriptCompiler's type-directed code generation, including the int type of boolean operands, and a bounded-exhaustive translation-validation harness: every expression tree of size up to 5 (702,226 trees, 13,147,954 evaluations per literal alphabet, two literal alphabets, two variables bound to 13 values), each compiled result compared bit for bit with the model (0 mismatches, so the model is faithful) and with a value-semantics reference (over all trees up to size 5 with the first literal alphabet, 237,419 evaluations differ, 145,857 of them a boolean operator over a long operand).
• Z3 bit-vector and floating-point queries then characterised the class: a non-zero long operand is false exactly when its low 32 bits are zero; the same value through the double path is never false; a single-bit test of bit 32 to 62 is false for every input (with a vacuity probe for bits below 32); bit 63 was later shown the same way by execution.
• The finder then wrote a public-API JUnit on the stock jar. Independent reproducers wrote their own tests from the claim alone; the one-test repro was cut from those on 2026-10-29.