Hunspell spell() accepts two-word flag compounds when COMPOUNDWORDMAX is 1 (or 0)

COMPOUNDWORDMAX n in a Hunspell affix file caps how many words a compound may have (hunspell(5): "Set maximum word count in a compound word"). Lucene's spell checker checks the cap only before it adds a third or later part: the check at the top of checkCompounds (Hunspell.java:214 on main a9779ef3c193) is skipped when there is no previous part, and checkCompoundsAfter (:269-286) accepts the first part plus a last part without counting. For a cap of 2 or more that is exact, but a cap of 1 never fires for a two-word compound. So with COMPOUNDFLAG C, COMPOUNDMIN 1, COMPOUNDWORDMAX 1 and the words foo/C, bar/C, spell("foobar") returns true, while C Hunspell 1.3.2 and 1.7.2 return false. COMPOUNDWORDMAX 0 (which the parser clamps to 1) and COMPOUNDBEGIN/COMPOUNDEND compounding behave the same; three or more words are still rejected. The code that added the directive (LUCENE-9699) rejected every flag compound at 1; the LUCENE-9729 refactoring dropped the first-part check before any release, so every release with the spell-checking API, 8.9.0 to 10.5.2, is affected. The reach is small: none of 477 public .aff files with the directive uses 0 or 1, and Lucene's stemming is not affected.

• Flag compound: a word Lucene accepts because its parts carry COMPOUNDFLAG, or COMPOUNDBEGIN / COMPOUNDMIDDLE / COMPOUNDEND. COMPOUNDMIN is the shortest allowed part (default 3).
• COMPOUNDWORDMAX n: hunspell(5) "Set maximum word count in a compound word. (Default is unlimited.)". Lucene parses it as Math.max(1, n) (Dictionary.java:439), so 0 acts as 1; the default is Integer.MAX_VALUE (:152).

1. foobar is not a dictionary word, so checkCompounds(char[], ...) (Hunspell.java:150-161) takes the flag path and calls checkCompounds(word, originalCase, null) (:157): no previous part.
2. That method starts with the only word-count check in the package's production code (:214): if (prev != null && prev.index > dictionary.compoundMax - 2) return false;. prev is null, so nothing is checked.
3. foo is found as a first part and wrapped in a CompoundPart with index 1 (:372); checkCompoundsAfter is called (:234-236).
4. checkCompoundsAfter (:269-286) finds bar as a valid last part and returns true (:276-281). It checks forbidden words, CHECKCOMPOUNDDUP, FORCEUCASE and mayCompound, but not the count.
5. Only when the rest is not a valid last part does it recurse with prev = foo (:285); then 1 > 1 - 2 rejects a third part.

So for a limit n >= 2 the check rejects exactly the (n+1)-th part, and for n = 1 the second, last part is never counted.

In compound_check the second word is accepted only if (cpdwordmax == -1) || (wordnum + 1 < cpdwordmax) (1.7.2 affixmgr.cxx:1928 and :2067; the same condition in compound_check_morph at :2516 and :2655), with wordnum 0 at the first call (hunspell.cxx:895). So 0 and 1 reject every two-word flag compound, unless the Hungarian COMPOUNDSYLLABLE escape on the same line applies, which Lucene does not implement.

Over grids with both flag styles, limits absent, 0, 1, 2 and 3, and words of 1 to 4 parts, Lucene and C disagree only on the two-word compound at 0 and 1 (70 cells against C 1.7.2: 4 mismatches; 48 comparisons against C 1.3.2: 6). C 1.7.2 and 1.3.2 both reject the exact foobar at 0 and 1 and accept it at 2, in both flag styles. suggest() uses the same check: at limit 1 it offered the over-limit compound northstar for the typo northstarr (not compared with C's suggestions).

• Who is hit. Callers of Hunspell.spell and Hunspell.suggest (lucene-analysis-common) with a dictionary that uses flag compounding and sets COMPOUNDWORDMAX 1 or 0. The checker is opt-in: the application loads a dictionary of its choice, and no default analyzer uses it.
• What they get. spell says "correct" for every two-word flag compound the dictionary can build, which is exactly what the author tried to forbid; suggest can offer such compounds. No exception, the same result with assertions on and off, deterministic, no scale needed.
• How likely. Low. The setting is self-contradictory (declare compound flags, then allow one word per compound). A code search found 477 public .aff files with COMPOUNDWORDMAX, none with 0 or 1 (values: 4 in 227 files, 2 in 148, 10 in 71, 3 in 20, 100 in 7, 7 in 4); it covers only what the search indexes. A maintainer who sets 1 to switch flag compounding off without removing the flags would hit it; no such dictionary is known.
• Not affected. Limits of 2 or more and the default (unlimited); three or more words at 1; COMPOUNDRULE compounds (compoundMax is never consulted there, and C Hunspell 1.3.2 also accepts two rule parts at 1); Lucene's stemming: Stemmer stems only simple words (Stemmer.java:94-103) and HunspellStemFilter calls it (HunspellStemFilter.java:108-114), so it never splits compounds ("No roots are returned for compound words", Hunspell.java:300). Code that calls spell or suggest in its own indexing or query pipeline does see the bug.
• Severity. A spell-check verdict error in an opt-in component for an unusual setting: impact minor, likelihood contrived, priority low. Best framed as a small consistency and C-parity fix.

# Lucene main 645d4fe14a20, assertions on (-ea), seed DEADBEEF: 1 test(s) run, 1 failed
    => java.lang.AssertionError: COMPOUNDWORDMAX 1: spell("foobar") (2 words) expected false, was true
       org.junit.Assert.fail(Assert.java:89)
       org.junit.Assert.assertTrue(Assert.java:42)
       org.junit.Assert.assertFalse(Assert.java:65)
       org.apache.lucene.analysis.hunspell.TestCompoundWordMaxOne.testTwoWordCompoundAtMaxOne(TestCompoundWordMaxOne.java:36)

• The format defines a word count. hunspell(5) of C Hunspell 1.7.2: "COMPOUNDWORDMAX number: Set maximum word count in a compound word. (Default is unlimited.)". A two-word compound exceeds a maximum of 1.
• Lucene aims at Hunspell behaviour. The class javadoc says the class "can be used in place of native Hunspell for many languages for spell-checking and suggesting purposes" (Hunspell.java:35-36). The promise is qualified ("Note that not all languages are supported yet. For example:" Hungarian, non-BMP characters, PHONE; :36-44); the list is not exhaustive, but none of its entries covers a compound word limit. spell returns "whether the given word's spelling is considered correct according to Hunspell rules" (:72).
• Lucene is inconsistent with itself. At 2, foobar is accepted and foobarfoo rejected (this doc's control test, the independent reproducer and the devil's advocate); at 3, three parts are accepted and four rejected (the last two); at 1, three words are rejected. Only the two-word case at 1 (and 0) differs.
• C Hunspell rejects it. 1.3.2 and 1.7.2 reject foobar at 1 and at 0 and accept it at 2, in both flag styles; a second 1.7.2 build (a Linux distribution package) agrees at 1 and 2. This follows wordnum + 1 < cpdwordmax with wordnum 0 at the first part; the rule's Hungarian COMPOUNDSYLLABLE escape is not set in these dictionaries.
• The original code enforced 1. LUCENE-9699 (a176308aa63, 2021-01-27, apache/lucene-solr#2248, issue #10738) added the directive with if (depth > dictionary.compoundMax - 2) return false;, run with depth 0 at the first part, so a limit of 1 rejected every flag compound (COMPOUNDRULE compounds were checked first, on a path without a limit). LUCENE-9729 (650f16ad5d8, 2021-02-05, apache/lucene-solr#2300, issue #10768, "Hunspell: support CHECKCOMPOUNDREP flags") replaced the depth counter by the CompoundPart chain and wrote the current guard; prev != null is the null guard that prev.index needs. The PR body, its single review comment (about CheckCompoundPattern offsets) and the issue never mention COMPOUNDWORDMAX. Commit-level runs: the parent 16764f16010 enforces 1, 650f16ad5d8 does not.
• Not a listed divergence. Lucene's test over C Hunspell's own test cases names the cases it expects to fail, TestHunspellRepositoryTestCases.EXPECTED_FAILURES (hu, morph, opentaal_keepcase, nepali, utf8_nonbmp, phone). That is an exception set for one test corpus, not a full catalogue of accepted differences; this case is not in it. Lucene's tests use COMPOUNDWORDMAX only with the value 2, as a parse check (forgivable-errors.aff, TestDictionary.testForgivableErrors); no test exercises the limit in spell.

The strongest case for "intended": (a) a limit of 1 is degenerate, because a compound has at least two words and an author who wants none would not declare a compound flag; (b) hunspell(5) presents COMPOUNDWORDMAX among the options for the Hungarian "6-3" rule (with COMPOUNDSYLLABLE, COMPOUNDROOT and SYLLABLENUM), and Lucene does not support Hungarian; C's count condition itself has a COMPOUNDSYLLABLE escape; (c) the Math.max(1, n) clamp could suggest that values below 2 were never meant to limit anything; (d) on the COMPOUNDRULE path C Hunspell 1.3.2 and Lucene both accept two parts at 1; (e) Lucene's parity promise is qualified ("for many languages", exceptions given "for example"), and every release has behaved this way.

Why it fails: (a) is about impact, not intent, and is reflected in the "minor" rating; the directive takes any number and the man page gives no lower bound. (b) Lucene parses and enforces COMPOUNDWORDMAX for every dictionary, and the trigger uses no Hungarian option. (c) The clamp came with LUCENE-9699, whose check did enforce 1 (0 and 1 behaved alike, as in C), so it never meant "no limit". (d) This report is about flag compounds only, where C enforces the limit and Lucene enforces it for 2 and 3. (e) A qualified promise does not make a silently lost check intended; the change came in a refactoring that never discussed the limit. Every reviewer rated the intended argument weak as a case that today's result is correct; the cross-model fact check rated it moderate as a "won't fix / very low priority" argument, so keep the issue small. Verdict: not intended, a defect.

One fix (A, the finder's one-line change) was applied in a scratch worktree at a9779ef3c193 and run through gradle, and shadowed onto the stock jars for every other repro of the hunt. B and C are alternatives that were not run.

Hunspell.java only, +3/-1. With no previous part, the compound being built has at least two words, so it is allowed only if compoundMax >= 2. This restores the LUCENE-9699 behaviour (depth > compoundMax - 2 with depth 0) and matches C's wordnum + 1 < cpdwordmax with wordnum 0; later parts are unchanged. The check runs before the CHECKCOMPOUNDPATTERN replacements, so they are limited the same way. The COMPOUNDRULE path is untouched, and for 0 and 1 the Math.max(1, n) clamp needs no change. Open point, negative values: C treats -1 as "unlimited" (atoi, affixmgr.cxx:129, :1928), Lucene clamps every value below 1 to 1 (Dictionary.java:439). Executed: at -1, C 1.7.2 and 1.3.2 accept every compound, main accepts two words but rejects three, and with the fix every flag compound is rejected; at -2 the fix matches C. No surveyed dictionary uses a negative value; mapping -1 to unlimited would need its own decision and test.

   private boolean checkCompounds(CharsRef word, WordCase originalCase, CompoundPart prev) {
-    if (prev != null && prev.index > dictionary.compoundMax - 2) return false;
+    if (prev == null ? dictionary.compoundMax < 2 : prev.index > dictionary.compoundMax - 2) {
+      return false;
+    }

Trade-offs

One comparison per top-level call; no benchmark was run. Dictionaries with COMPOUNDWORDMAX 0 or 1 and compound flags stop accepting two-word compounds, which is what the directive says and what C Hunspell does.

What the checks validated

• Stock main a9779ef3c193, gradle: the repro fails 3 of 4 (the claim tests) with assertions on and off.
• With the fix, gradle: the repro passes 4 of 4 with assertions on and off; the whole lucene/analysis/common test task with assertions on, repro included, runs 340 classes, 1,913 tests, 0 failures, 18 skipped (the hunspell package: 47 classes, 162 tests, 13 skipped, because TestAllDictionaries, TestHunspellRepositoryTestCases and TestPerformance need external dictionaries; TestSpellChecking, 53 tests, passes); checkGoogleJavaFormat, ecjLint, forbiddenApisMain and forbiddenApisTest pass with fix and test in place.
• Classpath runner with the fix shadowed: this doc's test 4 of 4; the finder's test; the independent reproducer's 8 of 8; a 70-cell grid against C Hunspell 1.7.2 with 0 mismatches; 810 .good/.wrong expectations over 53 upstream dictionaries unchanged; a separate, narrower JUnit 4 class-path run of Lucene's hunspell test classes (all but TestHunspellRepositoryTestCases) passes 146 tests, a count not comparable with gradle's.
• Not run: the full Lucene suite, the external-dictionary suites, a benchmark.

Before accepting the last root (Hunspell.java:276-281), require prev.index + 1 <= compoundMax.

Trade-offs

Same effect, but it splits the limit check across two methods, and CHECKCOMPOUNDPATTERN replacements reach checkCompoundsAfter too. Not run.

Add && dictionary.compoundMax >= 2 to the flag-path condition in checkCompounds(char[], ...) (Hunspell.java:156).

Trade-offs

Smallest reasoning about the degenerate value, but it leaves the misleading first-part gap in the guard at :214. Not run.

Method: cross-implementation differential testing (not a formal method). A grammar generated small synthetic compounding dictionaries, with COMPOUNDWORDMAX drawn from {1, 2, 3}, and compared the stock jar's Hunspell.spell with C Hunspell 1.7.2 on the generated words.

• 11 disagreements came out (9 dictionaries of one seed, 2 of another), all with COMPOUNDWORDMAX 1 and a two-part compound; limits 2 and 3 never disagreed.
• The finder minimized them to the foo/bar dictionary, wrote a public-API JUnit, ran it on main (-ea, -da), 10.5.2 and 9.12.3, and checked C Hunspell 1.7.2 (a build from the release source, with the hunt's test hooks off, and a Linux distribution build) on the same files.
• Before submitting, an independent reviewer from another model family (OpenAI GPT-5.6) tried to refute the claim with its own test; it agreed, and pointed out that the original LUCENE-9699 code enforced a limit of 1.