mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Read MOSDocumentLockFile UTF-16 string data with same endianness

Browse Source 
...as MSODocumentLockFile::WriteEntryToStream has written it to (i.e.,
always as UTF-16LE, assuming that is actually the right format to use).  The
discrepancy between writing and reading the string data appears to be present
ever since the code's introduction in 5db1e20b8b
"Introduce new lockfile handler for MSO like lockfiles".

This caused CppunitTest_svl_lockfiles to fail on (big-endian) s390x Linux with

> svl/qa/unit/lockfiles/test_lockfiles.cxx:578:(anonymous namespace)::LockfileTest::testWordLockFileRT
> equality assertion failed
> - Expected: LockFile Test
> - Actual  : 䰀漀挀欀䘀椀氀攀 吀攀猀琀

etc.

Change-Id: I97267aa14a3a926e7fd7bb1d2ce7d2de05d52a64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103238
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This commit is contained in:
Stephan Bergmann
2020-09-23 11:53:11 +02:00
parent 535f280649
commit 1b9fa11a08
1 changed files with 10 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
svl/source/misc/msodocumentlockfile.cxx
View File

@@ -228,8 +228,16 @@ LockFileEntry MSODocumentLockFile::GetLockData()
nUTF16Len = *++pBuf; // use Excel/PowerPoint position
if (nUTF16Len > 0 && nUTF16Len <= 52) // skip wrong format
aResult[LockFileComponent::OOOUSERNAME]
= OUString(reinterpret_cast<const sal_Unicode*>(pBuf + 2), nUTF16Len);
{
OUStringBuffer str(nUTF16Len);
sal_uInt8 const* p = reinterpret_cast<sal_uInt8 const*>(pBuf + 2);
for (int i = 0; i != nUTF16Len; ++i)
{
str.append(sal_Unicode(p[0] | (sal_uInt32(p[1]) << 8)));
p += 2;
}
aResult[LockFileComponent::OOOUSERNAME] = str.makeStringAndClear();
}
}
}
return aResult;