mirror of
https://github.com/brazilofmux/tinymux
synced 2026-08-13 00:23:11 -04:00
3ad4b05d2c
Nothing in tests/ covered Unicode normalization. The combining-character smoke cases (graphemes, comp, chr) reach this code, but only incidentally: none of them asserts that a decomposed sequence composes, that marks are reordered by canonical combining class, or that the result is idempotent. That was the only evidence available when reviewing #1998, which moved this routine's 512 KB code-point table off the stack. 37 assertions, from two deliberately separate sources: - Unicode-mandated results -- base plus combining mark composing to the precomposed character, canonical ordering by CCC (dot-below ccc 220 must precede acute ccc 230, and equal-CCC marks must NOT be reordered), algorithmic Hangul L+V composition, and idempotence of the normal form over the whole corpus. These follow from the standard, so they are correct expectations independent of what this implementation does. - Characterization of choices the standard does not dictate: malformed UTF-8 is dropped, leading marks with no starter are preserved, and the two output-bound behaviours differ (the already-NFC fast path is a truncating memcpy; the slow path emits only whole characters that fit). These lock current behaviour so a change is visible rather than asserting it is required. Mutation-tested so the suite is known to have teeth: commenting out CanonicalOrder fails 2 assertions and commenting out CanonicalCompose fails 7. Reverting #1998's own change (static back to automatic) fails none, correctly -- it is a storage-class change with no behavioural effect, which is why that PR needed review rather than tests alone. Wired into make test (34 targets now, was 33) and into the sanitizer island list, where the bounds handling on the code-point table and nDstMax are worth instrumenting. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| Makefile | ||
| test_nfc.cpp | ||