Re: Fix for fragile code in ltree/crc32.c

On 22/08/2026 09:04, Rithvika Devisetti wrote:
> On Thu, 2026-08-20 at 13:32 -0700, Jeff Davis wrote:
> > Attached two patches. The first one is the same and backpatches through
> > 18. The second defines some new macros and uses those, which is a
> > better place to document the limits, and I'll only commit that one to
> > master.
>
> I applied both v2 patches and tested them on macOS 15 (aarch64,
> clang 21), built with meson and --enable-cassert. Reporting results in
> case an independent check on a non-Linux platform is useful.
>
> Full test suite passes: 360 tests OK, 0 failures. The 40 skips are all
> PG_TEST_EXTRA opt-ins (ssl, ldap, oauth, load_balance,
> libpq_encryption, xid_wraparound). I ran saslprep separately with
> PG_TEST_EXTRA=saslprep and it passes as well.
>
> To exercise the changed path specifically, I used a database with
> LOCALE_PROVIDER builtin / BUILTIN_LOCALE 'PG_UNICODE_FAST' and checked
> the expanding case mappings:
>
> upper('ß') -> 'SS' (2 codepoints)
> upper('ffl') -> 'FFL' (3 codepoints)
> upper('ΐ') -> 3 codepoints
> upper('ῷ') -> 3 codepoints
> casefold('ß') -> 'ss'
>
> and drove ltree_crc32_sz() via ltree tables with GiST and btree indexes
> over 1000 rows. No assertion failures from the new
> Assert(foldlen < sizeof(foldstr)).

Hmm, so the code has this:

> /*
> * Expansion factor of string length, not including terminating NUL. That is,
> * the upper bound of the number of multibyte characters in the result string
> * per multibyte character in the input string.
> *
> * NB: assumes no provider exceeds the Unicode-defined maximum.
> */
> #define PG_MAX_CASEMAP_MBCHARS UNICODE_MAX_CASEMAP_CODEPOINTS

Is it a number of codepoints or bytes? The comment says "multibyte
characters" which I think means codepoints in unicode, but the ltree
code does this:

> /* max space required to map single codepoint, including NUL */
> char foldstr[PG_CASEMAP_BUFSZ];

Which sure looks like # of bytes.

- Heikki