-
Notifications
You must be signed in to change notification settings - Fork 25
Description
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.