Test failures in version 3.37.0 on big endian architectures
(1) By Reinhard Max (reimax) on 2021-11-30 13:39:05 [link] [source]
On all big endian architectures supported by openSUSE Tumbleweed the test suite of SQLite 3.37.0 shows this failure:
[ 437s] ! windowB-2.0 expected: [{} 1 蕕郐䔓硑ᇍ䫎 1]
[ 437s] ! windowB-2.0 got: [{} 1 喅킐ፅ典촑칊 1]
Full build logs can be found here:
This does not happen with version 3.36.0 and not on any other architecture, especially not on PPC64LE, which is why I suspect an endianness problem.
(2) By Arfrever Frehtes Taifersar Arahesis (Arfrever) on 2021-12-14 18:01:58 in reply to 1 [source]
Note about identification of location:
These tests are in file test/windowC.test, not test/windowB.test.
test/windowC.test was probably created by copying some parts of test/windowB.test, and test/windowC.test still contains:
set testprefix windowB
This should be changed to:
set testprefix windowC
Failing test was added in commit 38a1326b4bd11bbe2846990d099c28520d17ab4cace1af67248c2472f89df929.
This commit introduced call to function sqlite3_value_text() about which documentation says:
** ^The sqlite3_value_text16() interface extracts a UTF-16 string
** in the native byte-order of the host machine. ^The
** sqlite3_value_text16be() and sqlite3_value_text16le() interfaces
** extract UTF-16 strings as big-endian and little-endian respectively.
This commit, in newly added test, included:
PRAGMA encoding=UTF16;
Some other syntactically valid values include:
PRAGMA encoding=UTF16LE;
PRAGMA encoding=UTF16BE;
On my little-endian system I get expected result 蕕郐䔓硑ᇍ䫎 with encoding UTF16 or UTF16LE, and I get result 喅킐ፅ典촑칊 with encoding UTF16BE.
Maybe changing this test to have PRAGMA encoding=UTF16LE; would be sufficient solution...