Ahoj, Dňa Sat, 8 Mar 2025 20:45:59 +1000 Adam Nielsen <a.nielsen@xxxxxxxxxxx> napísal: > If I run this in bash: > > $ echo $[0x100000000 - 3489577139] > 805390157 > > It gives me the same number you get in SQLite. This means you are > taking a number that needs 32-bits, and storing it in a place that > only has 31 bits for storage. It is probably a signed 32-bit > integer, which has 1 bit for sign and 31 bits for the number. OK, that my initial feel, that it has something with signed/unsigned, numbers was correct. Interesting is, that i tried almost the same calculation (2^32 - X) with bc, but i must did something wrong (or typo), now i get the same result as you... Initial investigation i did yesterday at night, i my eyes was really tired. > A quick Google suggests SQLite does this automatically. Yes, that is how i understand the SQLite's INT field -- up to 2^63 positive value, and all other *INT (SMALLINT, BIGINT, etc) definitions are just for readability of schema, more or less aliases for INT... IMO the same (more or less) applies to UNSIGNED definition. > This means SQLite or your schema is not at fault, but rather whatever > is handling the number before generating the SQL is using integers > that are too small (or are incorrectly signed). Eh, get all (wanted) fields from source/ulogd -i output is not very easy task, in mean that is is huge amount of fields, thus prone to mistake. Thank for confirmation, that schema is OK (at least in this case). > Possibly it is something calling printf() and passing %ld instead of > %lu for that field. I don't know, if ulogd2 does some decision based on SQLite's field type, or takes into account field's name only... I see in sources (ulogd_output_SQLITE3.c), eg. the ULOGD_RET_INT32 and its ULOGD_RET_UINT32 counterpart, but i don't see that counterpart for ULOGD_RET_INT64. For me, it is hard to say if that is important... regards -- Slavko https://www.slavino.sk
