Incorrect integer decoding (24, 48, 64 bit)

[CFPrulez]

As a minimal example, create the following database:

CREATE TABLE 'simpletable' (
	'name' TEXT,
	'8bitnumber' INTEGER,
	'16bitnumber' INTEGER,
	'24bitnumber' INTEGER,
	'32bitnumber' INTEGER,
	'48bitnumber' INTEGER,
	'64bitnumber' INTEGER
);

INSERT INTO 'simpletable' 
	('name', '8bitnumber', '16bitnumber', '24bitnumber', '32bitnumber', '48bitnumber', '64bitnumber')
	VALUES
	('undark', 117, 322, 110590, 181075936, 20015998341138, 81985529216486895),
	('undark', 15, 242, 45054, 13303776, 2882343476, 320255973501901);

Expected result:

2,"undark",15,242,45054,13303776,2882343476,320255973501901
1,"undark",117,322,110590,181075936,20015998341138,81985529216486895

Output of undark -i (version 0.6):

2,"undark",x15,242,11533898,13303776,0,0
1,"undark",x117,322,28311114,181075936,301989888,16777216

Output of undark -i (version 0.7.1):

2,"undark",x15,242,11533824,13303776,0,0
1,"undark",x117,322,28311040,181075936,301989888,16777216

First Observation:
– 8-bit integer: correct (but with "x")
– 16-bit integer: correct
– 24-bit integer: wrong
– 32-bit integer: correct
– 48-bit integer: wrong
– 64-bit integer: wrong

Second Observation:
Undark’s result for 48- and 64-bit is simply wrong in the first row and 0 in the second row.
Where’s the differece between row 1 and row 2?

Hexdump of rowid 1 (already splitted correctly):
|| 26 || 01 || 08 | 19 | 01 | 02 | 03 | 04 | 05 | 06 || 75 6e 64 61 72 6b | 75 | 01 42 | 01 af fe | 0a ca ff e0 | 12 34 56 78 90 12 | 01 23 45 67 89 ab cd ef ||

Hexdump of rowid 2 (already splitted correctly):
|| 26 || 02 || 08 | 19 | 01 | 02 | 03 | 04 | 05 | 06 || 75 6e 64 61 72 6b | 0f | 00 f2 | 00 af fe | 00 ca ff e0 | 00 00 ab cd 12 34 | 00 01 23 45 67 89 ab cd ||

As we can see, rowid 2’s integer start with nullbytes. Maybe that’s an explanation why 0 is the result of 48- and 64-bit in the second row?

Third Observation:
This third issue has already been fixed in version 0.7.1 and affects only v0.6.
The result of 24-bit integers is not reproducible. Using v0.6 the result of the 24-bit integer changes every time (e.g. of rowid 2): 11533920, 11533825, 11534016, 11533897, …
The first four digits are stable, the last four are changing.

[inflex]

Thankyou for the detailed writeup. Soon as I get a free moment I'll set about to see what I can find is the cause in the code.