Hunspell AF alias count silently wraps to a smaller value

Hi, I found a potential bug in PostgreSQL's Hunspell dictionary parser where an over-wide `AF` alias count in an affix file is accepted after being silently converted to a smaller positive integer, without any error or warning. Description: An affix file declaring `AF 4294967297` (which exceeds the maximum value representable in a 32-bit unsigned integer by 1) but containing only one alias definition loads successfully and behaves as if it declared one alias. The parsing path appears to use a narrow integer conversion and validates only the converted value, not whether the original number can be represented without loss. PostgreSQL version: - PostgreSQL 19beta3 (Docker-based runtime) - Source commit: not recorded in the original report - Build relationship: the tested image was not an exact-HEAD build Environment: - Docker-based PostgreSQL 19beta3 runtime - Hunspell dictionary support enabled by default - No special server configuration required beyond superuser access to create dictionaries Steps to Reproduce: Create `af_overflow.affix` in PostgreSQL's `tsearch_data` directory: ```text SET UTF-8 AF 4294967297 AF A PFX A Y 1 PFX A 0 re .

Create af_overflow.dict:
text

book/1

Then, as a superuser, execute the following SQL:
sql

\set VERBOSITY verbose CREATE TEXT SEARCH DICTIONARY af_overflow (  TEMPLATE = ispell,  DictFile = af_overflow,  AffFile = af_overflow ); SELECT ts_lexize('af_overflow', 'rebook');

Actual Result:

The dictionary is created successfully without any error. ts_lexize returns:
text

{book}

The declared value 4294967297 effectively behaves as if the alias count was 1, which matches the number of defined aliases.

Expected Result:

The loader should reject an AF count that is out of range, cannot be converted losslessly, or does not match the number of alias definitions. An explicit error message such as "AF alias count out of range" or "number of AF aliases does not match declaration" would be appropriate.

Reproduction Frequency:

Positive reproduction: 2/2 on PostgreSQL 19beta3

Negative control: replacing the count with AF 1 loads and lexizes normally

Additional Observations:

This appears to be a low-impact issue because it requires elevated privileges to install dictionary files and create text-search dictionaries. However, it could lead to subtle misbehavior if a dictionary file with an overflowed count is accidentally used. The issue is likely located in the affix-file parsing code where the AF count is converted without checking for overflow or loss of precision.

I searched the public PostgreSQL bug archives and did not find any report specifically addressing overflow handling of AF alias counts. Please confirm whether this is considered a bug or an intentional limitation of the parsing logic.

♂π≌26218
1991230470(at)qq(dot)com