Skip to content

Fix string hashing for utf16 strings - #1376

Open
tobil4sk wants to merge 4 commits into
HaxeFoundation:masterfrom
tobil4sk:fix/utf16-string-hash
Open

Fix string hashing for utf16 strings#1376
tobil4sk wants to merge 4 commits into
HaxeFoundation:masterfrom
tobil4sk:fix/utf16-string-hash

Conversation

@tobil4sk

@tobil4sk tobil4sk commented Aug 25, 2026

Copy link
Copy Markdown
Member

Closes #1375.

String::hash was broken for (non-literal) utf16 strings because it didn't handle the isUTF16Encoded() case.
String::calcHash also did not handle surrogate pairs correctly, and instead iterated on individual code units.

During hashing, invalid utf16 code units are replaced with the replacement character (Char16Advance with throwOnErr = false). This avoids introducing exceptions to code that wasn't throwing before, however, it means two different invalid utf16 strings can have hashes that collide. This seems to be an ok compromise.

Outside the BMP, characters take two utf16 code units. The old hashing
was incorrect as it would only ever read a single unit at a time, and
therefore calculate the wrong hash for a string containing a non-BMP
character.

The Char16Advance call handles this, ensuring that surrogate pairs are
read as a single code point.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StringMap bug when using an emoji string parsed from JSON in C++ backend

1 participant