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> |
||
---|---|---|
.. | ||
largefile | ||
qabstractfileengine | ||
qbuffer | ||
qdatastream | ||
qdataurl | ||
qdebug | ||
qdir | ||
qdiriterator | ||
qfile | ||
qfileinfo | ||
qfileselector | ||
qfilesystementry | ||
qfilesystemwatcher | ||
qiodevice | ||
qipaddress | ||
qlockfile | ||
qloggingcategory | ||
qloggingregistry | ||
qnodebug | ||
qprocess | ||
qprocess-noapplication | ||
qprocessenvironment | ||
qresourceengine | ||
qsavefile | ||
qsettings | ||
qstandardpaths | ||
qstorageinfo | ||
qtemporarydir | ||
qtemporaryfile | ||
qtextstream | ||
qurl | ||
qurlinternal | ||
qurlquery | ||
qwinoverlappedionotifier | ||
io.pro |