Commit 507171b5 authored by Volker Krause's avatar Volker Krause Committed by Torsten Rahn
Browse files

Fix string length computation for O5M encoding

We need to consider the UTF-8 encoded string length here, which can differ
from the QString length previously used. In most cases the difference isn't
relevant, but I have encountered two tiles so far where those values not
only differed, but ended up on either side of the 250 character limit here.
If that happens the string table in the o5m decoder when reading this ends
up in an inconsistent state, and produces spectacularly messed up tags.

While at it, also sharpen the asserts here, violating either of those would
produce invalid o5m output.
parent 9dd870a6
......@@ -308,8 +308,9 @@ void O5mWriter::writeStringPair(const StringPair &pair, StringTable &stringTable
stream.writeRawData(m_stringPairBuffer.constData(), m_stringPairBuffer.size());
bool const tooLong = pair.first.size() + pair.second.size() > 250;
bool const tooLong = (m_stringPairBuffer.size() - (pair.second.isEmpty() ? 2 : 3)) > 250;
bool const tableFull = stringTable.size() > 15000;
if (!tooLong && !tableFull) {
/* When the table is full, old values could be re-used.
* See o5m spec. This is only relevant for large files and would
......@@ -318,7 +319,8 @@ void O5mWriter::writeStringPair(const StringPair &pair, StringTable &stringTable
} else {
auto const reference = stringTable.size() - iter.value();
Q_ASSERT(reference >= 0);
Q_ASSERT(reference > 0);
Q_ASSERT(reference <= stringTable.size());
writeUnsigned(reference, stream);
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment