Bug 396057 - Pascal-style RLE strings not working properly for length 1, both JS and OSD
Summary: Pascal-style RLE strings not working properly for length 1, both JS and OSD
Status: RESOLVED FIXED
Alias: None
Product: okteta
Classification: Applications
Component: Structures Tool (other bugs)
Version First Reported In: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Alex Richardson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-01 17:17 UTC by SasQ
Modified: 2022-05-23 10:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 0.26.9
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SasQ 2018-07-01 17:17:45 UTC
The following simple test structure definition for recognizing Pascal-style (run length ncoded) strings works only for strings longer than 1 byte, but for lengths 1 and 0 shows that the string has length 0 while still containing the previous content (sometimes with garbage characters at the beginning):

function init() {
	var obj = struct({
		len: uint16(),
		data: string("utf-8")
	});
	obj.byteOrder = "big-endian";
	obj.child("data").updateFunc = function() {
		this.maxByteCount = this.parent.len.value;
	};
	return obj;
}

Or the same expressed in the XML format:

<?xml version="1.0" encoding="UTF-8"?>
<data>
	<struct name="PascalString" byteOrder="big-endian">
		<primitive name="len" type="uint16" />
		<string name="data" encoding="utf-8" updateFunc="function() { this.maxByteCount = this.parent.len.value; }">
	</struct>
</data>

Here's a sample data I select:

00 04 41 42 43 44 45 46 47 48    |..ABCDEFGH    |

In this case, it correctly contains only a 4-byte string, "ABCD" (4).
But when I change the data to this:

00 01 41 42 43 44 45 46 47 48    |..ABCDEFGH    |

it contains a 0-byte string which is not empty! "BCDEFGH\0" (0).
It seems like it doesn't update the content of the string buffer / pointer to it, but updates the length to be 0 instead of 1.

A correct/expected behaviour should be a 1-byte string: "A" (1).
A 0-byte string should be a result when the length field in the data structure is set to `00 00`, and the contents of the string should be empty in that case, not contain the previously stored value: "" (0).

My version of Okteta is 0.12.5, which from some reason wasn't on the list. (KDE version 4.14.3)
Comment 1 Friedrich W. H. Kossebau 2022-05-23 10:15:42 UTC
Git commit aaea006c23cf1bb4471d11e7d3cc8cf45e1184ca by Friedrich W. H. Kossebau.
Committed on 23/05/2022 at 09:32.
Pushed by kossebau into branch '0.26'.

Structures tool: clear any existing string data on reading zero-byres string

M  +1    -0    kasten/controllers/view/structures/datatypes/strings/utf16stringdata.cpp
M  +1    -0    kasten/controllers/view/structures/datatypes/strings/utf32stringdata.cpp
M  +1    -0    kasten/controllers/view/structures/datatypes/strings/utf8stringdata.cpp

https://invent.kde.org/utilities/okteta/commit/aaea006c23cf1bb4471d11e7d3cc8cf45e1184ca
Comment 2 Friedrich W. H. Kossebau 2022-05-23 10:15:50 UTC
Git commit 4c95f98a3ce12b8517ea10058e59016336165b17 by Friedrich W. H. Kossebau.
Committed on 23/05/2022 at 09:37.
Pushed by kossebau into branch '0.26'.

Structures tool: fix condition for string maxBytes meaning empty string

FIXED-IN: 0.26.9

M  +1    -1    kasten/controllers/view/structures/datatypes/strings/utf32stringdata.cpp
M  +1    -1    kasten/controllers/view/structures/datatypes/strings/utf8stringdata.cpp

https://invent.kde.org/utilities/okteta/commit/4c95f98a3ce12b8517ea10058e59016336165b17