764f5bf48c
Saving strings with embedded zero-bytes (\0) as CFStrings would sometimes fail, and only write the part of the string leading up to the first zero-byte, instead of all the way to the final zero-terminator. This bug was revealed by the code-path that falls back to storing e.g. QTime as strings, via the helper method QSettingsPrivate::variantToString(). We now use the same approach as on platforms such as Windows and WinRT, where the string produced by variantToString() is checked for null-bytes, and if so, stored using a binary representation instead of as a string. For our case that means we fall back to CFData when detecting the null-byte. To separate strings from regular byte arrays, new logic has been added to variantToString() that wraps the null-byte strings in @String(). That way we can implement a fast-path when converting back from CFData, that doesn't go via the slow and lossy conversion via UTF8, and the resulting QVariant will be of type QVariant::ByteArray. The reason for using UTF-8 as the binary representation of the string is that in the case of storing a QByteArray("@foo") we need to still be able to convert it back to the same byte array, which doesn't work if the on-disk format is UTF-16. Task-number: QTBUG-56124 Change-Id: Iab2f71cf96cf3225de48dc5e71870d74b6dde1e8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> |
||
---|---|---|
.. | ||
.gitattributes | ||
.gitignore | ||
BLACKLIST | ||
bom.ini | ||
qsettings.pro | ||
qsettings.qrc | ||
resourcefile2.ini | ||
resourcefile3.ini | ||
resourcefile4.ini | ||
resourcefile5.ini | ||
resourcefile.ini | ||
tst_qsettings.cpp |