[PeterToulouras]

decode_flagset has a fast lane that decodes a flag field as a literal flag whenever FLAG num is set, without consulting the AF alias table. So for a dictionary that uses both FLAG num and AF, an entry like word/1 ends up with the literal flag 1 instead of expanding alias #1, and any affix rule referenced through an alias fails to match.

An AF table should take priority over the flag type. Hunspell resolves the field as an alias index whenever the table is non-empty and only decodes a literal flag when there is no table: https://github.com/hunspell/hunspell/blob/2969be996acad84b91ab3875b1816636fe61a40e/src/hunspell/hashmgr.cxx#L652-L660. Nuspell does the same, and hunspell.5 doesn't specify the precedence.

The fix drops the FlagType::Numeric short-circuit so the fast lane only applies when there are no aliases. The existing alias-index lookup then covers numeric dictionaries too, and out-of-range indices or non-integer fields still fall through to the literal decode unchanged.

I ran into this with the Korean dictionary: it uses FLAG num with an AF table, and its suffix (josa) rules are all referenced through aliases, so with the fast lane every suffixed word was reported as misspelled.

I extended decode_flagset_test to cover alias resolution under FLAG num along with the out-of-range and no-alias-table fallbacks.

[the-mikedavis]

This looks correct to me. I don't really remember the reasoning for this fast-lane - I might've just assumed that numeric flags can't use aliases.

I'm not sure how I feel about code from Claude though, ideally I want contributions to be understood fully by their implementor. Would you mind taking another swing at this from scratch, knowing the fix direction? If I get a chance I will try to do the same (and credit you with co-author of course).

[PeterToulouras]

Thanks for taking a look. I understand the reluctance to accept AI generated code given the huge amounts of slop being generated. Rationale for leaning on AI here:

• The change itself is narrow, and the issue is reproducible
• The fix is based off the existing c++ implementation of Hunspell https://github.com/hunspell/hunspell/blob/v1.7.2/src/hunspell/hashmgr.cxx#L652-L660 giving Claude a reference implementation to base off as opposed to a blind judgement call.

However, feel free to own the implementation/reimplement if you are more comfortable with that approach.

[the-mikedavis]

Thanks!