Automata.makeDecimalInterval accepts a negative min and silently returns a wrong automaton

Automata.makeDecimalInterval(min, max, digits) builds an automaton that accepts the decimal numbers from min to max written as text; its javadoc says it accepts "non-negative integers in the given interval" and names two cases that throw IllegalArgumentException: min > max, and max not fitting in digits. A negative min is in neither list and is not checked. The code turns it into a string with Integer.toString, keeps the -, and builds the automaton digit by digit as if - were a digit just below 0.

For (-1, 5, 0) the call returns without error an automaton that rejects "0" to "4" and accepts "12", "49", "-1" and "-5". For an "all ints" range (Integer.MIN_VALUE, Integer.MAX_VALUE, 0) it rejects every digit string of up to five characters. Some all-negative ranges, such as (-15, -1, 0), throw StringIndexOutOfBoundsException instead; others, such as (-5, -1, 0), silently accept "-1", "-5" and "0-1". RegExp, the only non-test caller inside Lucene, cannot pass a negative bound, so only applications that call the experimental Automata API directly are affected. The check condition has not changed since the code was imported in 2010. A one-condition fix (reject min < 0) passes the repro, the automaton tests and check -x test.

1. No check for a negative min. String x = Integer.toString(min); String y = Integer.toString(max); (:504-505), then the only check, if (min > max || (digits > 0 && y.length() > digits)) throw new IllegalArgumentException(); (:506-508). For (-1, 5, 0): x = "-1", y = "5", no exception.
2. Padding keeps the sign. Both strings are left-padded with '0' to d characters, d = digits, or y.length() when digits <= 0 (:509-523). Here d = 1 and x is already two characters long, so nothing changes. Padding only lengthens; it never removes the -.
3. The builder assumes two digit strings of equal length. between(builder, x, y, 0, initials, digits <= 0) (:534); its javadoc says the length of x.substring(n) "must be equal to y.substring(n).length()" (:232-236).
4. '-' becomes a digit. At position 0, cx = '-' (0x2D, just below '0') and cy = '5' (:251-252). They differ, so between() adds (:256-261): a transition on '-' into atLeast("-1", 1), which accepts "-1" to "-9"; a transition on '5', which accepts "5"; and a transition on the range '.' to '4' into anyOfRightLength("-1", 1) (:182-190), which wants one more digit. So "00" to "49", and "." or "/" followed by one digit (".0" to "/9"), are accepted, and "0" to "4" alone are not.
5. Leading zeros. With digits <= 0 a '0' loop is put in front (:538-544), so "05" is accepted too.
6. Some all-negative ranges throw. For (-15, -1, 0): x = "-15", y = "-1", d = 2, and x stays three characters long. between() matches '-' and '1', then reads y.charAt(2) (:252) on a two-character string: StringIndexOutOfBoundsException: Index 2 out of bounds for length 2. This happens only when the padded y is a proper prefix of x: between() stops at the end of x (:245) and reads y only while the two agree (:251-254). Other all-negative ranges return without error: (-5, -1, 0) accepts "-1", "-5" and "0-1"; (-1, -1, 0) and (Integer.MIN_VALUE, -1, 0) accept "-1" and "0-1".

• (0, 5, 0): accepts 0, 1, 4, 5, 05; rejects 6, 12, 49, -1, -5, 12345 (the control).
• (-1, 5, 0): accepts 5, 05, 12, 49, -1, -5; rejects 0, 1, 4. Exhaustively over all strings of length 0 to 5 on -./0123456789, it accepts 292 strings outside the documented language. With a fixed width, (-1, 5, 2) accepts "00" to "05" correctly, but also "-1" to "-9" and ".0" to "/9".
• (Integer.MIN_VALUE, Integer.MAX_VALUE, 0): rejects all 111,110 digit strings of length 1 to 5, "0" and "5" included.
• (-15, -1, 0) and (-100, -1, 0): StringIndexOutOfBoundsException. (-5, -1, 0): no exception; accepts "-1", "-5" and "0-1".
• Assertions on or off make no difference.

• Who is hit. Application code that calls the public static Automata.makeDecimalInterval directly with a negative min: an "all ints" range, or a lower bound computed from data. The class is @lucene.experimental.
• Not reachable from queries. RegExp.toAutomaton is the only production caller (RegExp.java:728-729). Its <n-m> parser rejects a - at the start, at the end, or a second - (RegExp.java:1474) and turns a NumberFormatException into IllegalArgumentException (:1489-1490), so it never passes a negative bound: new RegExp("<-1-5>") throws IllegalArgumentException: interval syntax error at position 5. RegexpQuery and the query parsers go through RegExp.
• What goes wrong. Mostly no exception, and an automaton with the wrong language. For (-1, 5, 0) it is wrong in both directions: in-range values are missing, values above max and strings with - are present; for (-1, 5, 2) nothing in range is missing, but strings with -, . or / are added. Whatever the caller builds from it, for example an AutomatonQuery, uses that language. Some all-negative ranges, such as (-15, -1, 0), fail loudly with an undocumented StringIndexOutOfBoundsException instead; others, such as (-5, -1, 0), silently accept "-1", "-5" and "0-1".
• Limits. Deterministic, no index data, no shared state. No resource blow-up relative to the min = 0 control: in the probe (digits up to 1,000) the largest negative-min automaton had 1,079 states against 1,003 for the control with the same digits, and every call took under 10 ms. Both grow with digits, which the caller chooses, so these are not general bounds.
• Likelihood: rare. The javadoc's "non-negative integers" steers careful callers away, nothing in Lucene passes a negative min, and no earlier report was found. One downstream direct caller is known, but whether it can pass a negative value was not checked.

The test sits in the automaton test package, as Lucene's own automaton tests do, but uses no package-private member. Nothing in it is randomized; seeds DEADBEEF and 5EED1234 give the same failure. Its assertion holds for both expectations (an exception, or the non-negative part of the interval), so it fits either fix.

As the regression test it needs one lint change: Lucene's ecj settings make an unused catch parameter an error (gradle/validation/ecj-lint/ecj.javadocs.prefs:136), so it has to be annotated as QueryParserBase.java:803-805 does, in the layout google-java-format requires:

    } catch (
        @SuppressWarnings("unused")
        IllegalArgumentException acceptable) {

With that change it fails on stock, passes with the recommended fix, and :lucene:core:check -x test (google-java-format, ecj lint including its javadoc rules, forbidden APIs) passes with it in place.

The second symptom, StringIndexOutOfBoundsException for (-15, -1, 0), has the same root cause and the same fix; it is left out of the test.

TestMakeDecimalIntervalNegativeMin > testNegativeMin FAILED
    java.lang.AssertionError: accepted among [0, 12] expected:<[0]> but was:<[12]>
        at __randomizedtesting.SeedInfo.seed([DEADBEEF:70C4BD88EB8BECE2]:0)
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:120)
        at org.apache.lucene.util.automaton.TestMakeDecimalIntervalNegativeMin.testNegativeMin(TestMakeDecimalIntervalNegativeMin.java:36)
:lucene:core:test (FAILURE): 1 test, 1  failure

# the same message with -Ptests.asserts=false, and on the 10.6.0 release jars

# probe on the same main (assertions on and off give the same lines):
makeDecimalInterval(0, 5, 0): accepts [0, 1, 4, 5, 05], rejects [6, 12, 49, -1, -5, 12345]
makeDecimalInterval(-1, 5, 0): accepts [5, 05, 12, 49, -1, -5], rejects [0, 1, 4, 6, 12345], same language as (0, 5, 0): false
makeDecimalInterval(-15, -1, 0): throws java.lang.StringIndexOutOfBoundsException: Index 2 out of bounds for length 2
makeDecimalInterval(-2147483648, 2147483647, 0): accepts [], rejects [0, 1, 4, 5, 6, 05, 12, 49, -1, -5, 12345], same language as (0, 2147483647, 0): false
new RegExp("<0-5>").toAutomaton(): ok
new RegExp("<-1-5>").toAutomaton(): throws java.lang.IllegalArgumentException: interval syntax error at position 5

• The documented contract. "Returns a new automaton that accepts strings representing decimal (base 10) non-negative integers in the given interval." @param min minimal value of interval. @exception IllegalArgumentException if min > max or if numbers in the interval cannot be expressed with the given fixed number of digits (Automata.java:490-499).
• Wrong unless a negative min is outside the contract. The non-negative integers in [-1, 5] are 0 to 5, which is what (0, 5, 0) returns. The automaton rejects 0 to 4 and accepts 12, so even the most lenient reading ("only the non-negative part counts") gets a wrong answer, not a narrower one.
• Tests cover only min >= 0. TestAutomaton.testIntervalRandom draws min from 0 to 100,000 (TestAutomaton.java:594), the random-operations test from 0 to 999 (:1105), and every other test call uses fixed non-negative bounds (TestAutomaton.java:342, 577, 586, TestRegExpParsing.java:474, 487, TestAutomatonQuery.java:134, 138). No test, comment or discussion says negative bounds are unsupported.
• Precedent. GITHUB#12427 (9.9.0): Automata#makeStringUnion now "explicitly throw[s] IllegalArgumentException if input data is not properly sorted instead of relying on assert" (lucene/CHANGES.txt:3121-3123).

The strongest case (rated moderate by the cross-model reviews): "non-negative integers" in the summary is an implied precondition; RegExp documents numeric intervals as "specified by non-negative decimal integers" (RegExp.java:347-348) and enforces it; every caller and test obeys it; the class is experimental; the code is an unchanged port of dk.brics.automaton, whose makeInterval has the same check. So a negative min is garbage in, garbage out.

Why it fails: the method does validate its arguments, and its documented list of rejected inputs leaves min < 0 out, so a caller gets no signal. An input that passes the method's own check should not yield an automaton that rejects "0" for [-1, 5], or a StringIndexOutOfBoundsException. The argument is a good reason to treat this as low-impact missing validation and to let maintainers choose between rejecting and clamping; it does not make the current output correct.

Both options were run in a scratch worktree of 645d4fe14a20 (OpenJDK 25.0.3, seed DEADBEEF), removed afterwards. "Automaton tests" means :lucene:core:test --tests 'org.apache.lucene.util.automaton.*' --tests org.apache.lucene.search.TestAutomatonQuery --tests org.apache.lucene.search.TestRegexpQuery. The choice is the maintainers': reject a negative min, or accept it as 0.

In Automata.makeDecimalInterval (Automata.java:498-499, 506): one code line and two javadoc lines. It matches the summary sentence ("non-negative integers") and the RegExp interval syntax, and covers both symptoms: (-1, 5, 0), (-15, -1, 0) and (Integer.MIN_VALUE, Integer.MAX_VALUE, 0) all throw IllegalArgumentException.

-   * @exception IllegalArgumentException if min > max or if numbers in the interval cannot be
-   *     expressed with the given fixed number of digits
+   * @exception IllegalArgumentException if min < 0, if min > max or if numbers in the
+   *     interval cannot be expressed with the given fixed number of digits
@@
-    if (min > max || (digits > 0 && y.length() > digits)) {
+    if (min < 0 || min > max || (digits > 0 && y.length() > digits)) {
       throw new IllegalArgumentException();

Trade-offs

• A caller that passes a negative min today gets an exception instead of a wrong automaton: a behaviour change; whether it needs a CHANGES entry is the maintainers' call.
• The exception stays the method's bare new IllegalArgumentException(); a message such as "min must be >= 0, got " + min would help but is optional.
• RegExp is unaffected: it never passes a negative bound.

What the checks validated

• Stock 645d4fe14a20: the repro fails with assertions on and off.
• With the fix: the repro passes with assertions on and off; the automaton tests pass (258 tests, 2 skipped); :lucene:core:check -x test (google-java-format, ecj lint including its javadoc rules, forbidden APIs) passes with the lint-ready regression test in place, which passes too and fails on stock. That local check rendered no javadoc; :lucene:core:renderJavadoc run separately with the fix passes.
• Probe: (-1, 5, 0), (-15, -1, 0) and (Integer.MIN_VALUE, Integer.MAX_VALUE, 0) throw IllegalArgumentException; (0, 5, 0) and <0-5> are unchanged.

After the existing check, return makeEmpty() when max < 0, and use "0" as the lower bound when min < 0 (+6 lines), with the javadoc @param min minimal value of interval; a negative value is treated as 0. This is the "non-negative part of the interval" reading: (-1, 5, 0) has the same language as (0, 5, 0), (Integer.MIN_VALUE, Integer.MAX_VALUE, 0) the same as (0, Integer.MAX_VALUE, 0), and (-15, -1, 0) is empty (language equality checked with Operations.minus both ways).

     if (min > max || (digits > 0 && y.length() > digits)) {
       throw new IllegalArgumentException();
     }
+    if (max < 0) {
+      return makeEmpty(); // no non-negative integer lies in the interval
+    }
+    if (min < 0) {
+      x = "0";
+    }

Trade-offs

• It accepts what is arguably a caller mistake without any signal.
• It adds a new documented behaviour to an experimental API, in more lines than rejecting.
• "Empty when max < 0" depends on order: the clamp runs after the existing width check, which counts the -, so (-15, -1, 1) still throws IllegalArgumentException while (-15, -1, 2) returns the empty automaton.

What the checks validated

• The repro passes and the automaton tests pass (258 tests, 2 skipped); check was not run for this option.
• Probe: the languages listed above, and RegExp unchanged.

A javadoc-only change (@param min minimal value of interval, must be non-negative). It closes the contract gap on paper but leaves the silent wrong automaton and the StringIndexOutOfBoundsException; the repro still fails. It fits naturally into the reject option.

Trade-offs

• No behaviour change, so no protection for callers.

What the checks validated

Not run (a javadoc change cannot make the repro pass).

Method: semi-formal (the finder's label; it sits at the boundary with non-formal testing).

• A pass over the real jars' bytecode with the JDK ClassFile API listed, for 27 core and module jars, 1,231 public entry points that can throw IllegalArgumentException, with the parameters and constants each guard tests. For makeDecimalInterval the only guards are min > max and the digit count.
• A dynamic probe called 134 of these methods 2,851 times with values derived from the guard constants, on the real jar, and recorded that makeDecimalInterval accepts min = -1 and Integer.MIN_VALUE.
• The tool's own output was only "accepted". The wrong-language oracle was the finder's public-API JUnit test against the javadoc's interval semantics; an independent reproducer then compared every string of length 0 to 5 over -./0123456789 with the documented language and found the StringIndexOutOfBoundsException.