Problem
CMakeLists.txt passes /Zc:__cplusplus to MSVC but not /utf-8. Without it, MSVC decodes a source file's non-ASCII bytes using the system codepage rather than UTF-8 (absent a BOM), so wide literals written with literal characters do not produce the code points the source text shows.
tests/database_test.cc contains such literals, for example at line 106:
const Person p{L"παναγιώτης", L"ανδριανόπουλος", 39, 1};Impact
These tests pass on Windows while testing nothing about non-ASCII handling. The mangled literal is used both as the input and as the expected value, so the comparison is self-consistent regardless of what the compiler actually produced — and the mangled form is plain Latin-1, entirely within the BMP, so it round-trips through SQLite without trouble.
This was found while fixing #25. The suite looked like it had non-ASCII coverage on Windows; it did not. The non-BMP corruption fixed in #25 had been present the whole time with a green CI matrix.
Suggested direction
Add /utf-8 to the MSVC compile flags so source bytes are interpreted as UTF-8 on every platform, and confirm the existing Greek literals still pass once they represent actual Greek on Windows.
Worth deciding separately whether tests should keep using literal characters at all. The tests added in #25 (tests/utf8_test.cc) deliberately use universal-character escapes (L"\u03C0") plus exact-byte assertions, which are immune to the source charset and do not depend on this flag. That convention could be applied more widely, in which case /utf-8 becomes a defense in depth rather than the fix.
Note the flag affects the source and execution character set for narrow literals. The narrow literals in this codebase are ASCII SQL, so the blast radius should be small, but it is a global build-flag change and was deliberately kept out of the #25 bug fix for that reason.
Problem
CMakeLists.txtpasses/Zc:__cplusplusto MSVC but not/utf-8. Without it, MSVC decodes a source file's non-ASCII bytes using the system codepage rather than UTF-8 (absent a BOM), so wide literals written with literal characters do not produce the code points the source text shows.tests/database_test.cccontains such literals, for example at line 106:Impact
These tests pass on Windows while testing nothing about non-ASCII handling. The mangled literal is used both as the input and as the expected value, so the comparison is self-consistent regardless of what the compiler actually produced — and the mangled form is plain Latin-1, entirely within the BMP, so it round-trips through SQLite without trouble.
This was found while fixing #25. The suite looked like it had non-ASCII coverage on Windows; it did not. The non-BMP corruption fixed in #25 had been present the whole time with a green CI matrix.
Suggested direction
Add
/utf-8to the MSVC compile flags so source bytes are interpreted as UTF-8 on every platform, and confirm the existing Greek literals still pass once they represent actual Greek on Windows.Worth deciding separately whether tests should keep using literal characters at all. The tests added in #25 (
tests/utf8_test.cc) deliberately use universal-character escapes (L"\u03C0") plus exact-byte assertions, which are immune to the source charset and do not depend on this flag. That convention could be applied more widely, in which case/utf-8becomes a defense in depth rather than the fix.Note the flag affects the source and execution character set for narrow literals. The narrow literals in this codebase are ASCII SQL, so the blast radius should be small, but it is a global build-flag change and was deliberately kept out of the #25 bug fix for that reason.