diff options
author | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2016-10-03 18:41:30 +0200 |
---|---|---|
committer | Tor Arne Vestbø <tor.arne.vestbo@qt.io> | 2016-10-18 14:35:08 +0000 |
commit | 4cb614c7abdaa2c5e2d0a75201d51aae01e6f8c4 (patch) | |
tree | a49ac5bc0b10054575dff75589b5c4f4ef411f98 /src/corelib/json/qjsondocument.cpp | |
parent | 158231e073eb2f94e7a6dfbf071dc2f34283321a (diff) |
Apple OS: Handle QSetting strings with embedded zero-bytes
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
Cherry-picked: 764f5bf48cc87f4c72550b853ab93b815454cd48
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'src/corelib/json/qjsondocument.cpp')
0 files changed, 0 insertions, 0 deletions