Strict input files validation and user-friendly error reporting

[ssvb]

Hunspell happens to have a rather non-transparent and user unfriendly validation of the input files. It just interprets various suspicious constructs in the input files in some deterministic way without saying anything. For example:

• the SFX/PFX directives can be indented by whitespace characters and are still recognized
• some of the other directives, such as NEEDAFFIX, are ignored if they are indented
• the words counter in the first line of a .dic file is ignored and words are loaded regardless of the actual counter value
• the indented words in a .dic file are ignored
• the stems in a .dic file may have invalid non-existing flags listed in the flags affix field. Hunspell seems to just ignore that particular invalid flag but process the rest of the data.
• ... and many other peculiarities like this

This situation is not ideal. Hunaftool needs to precisely emulate the Hunspell's behaviour to interpret the input data in the same way. On the other hand, all suspicious/ambiguous constructs in the .aff and .dic input files need to be reported to the user. If the user is a dictionary maintainer, then they may be encouraged to resolve these ambiguities in the input files.

[ssvb]

There are also strange cases like hunspell/hunspell#1045 which may be tricky to emulate. Such emulation even can't be done without first investigating and comprehending what's going on.

[fin-w]

the words counter in the first line of a .dic file is ignored and words are loaded regardless of the actual counter value

I think I remember reading that this number is related to memory (?) optimisation, but don't quote me on that.

[ssvb]

I think I remember reading that this number is related to memory (?) optimisation, but don't quote me on that.

Maybe some early implementation worked this way, but then later they "improved" the user experience by accepting poorly-made non-conforming files? I think that this silent behaviour is only doing disservice to the users.

And BTW, my favourite case of input validation weirdness so far:

SFX A y 10
[... 10 rules ...]

The cross product flag y here is silently interpreted as N!