interimap: fix handling of mod-sequence values greater or equal than 2 << 63.

SQLite processes every INTEGER values as a 8-byte signed integer, so we
need to manually do the conversion from/to uint64_t client-side if we
don't want to overflow or receive floats.

https://www.sqlite.org/datatype3.html#storage_classes_and_datatypes
http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/

We could also do the same trick for local/remote UIDs, UIDVALITY and
UIDNEXT values to slim the database down at the expense of pre/post-
processing.  (Values of SQLite's INTEGER class are 1, 2, 3, 4, 6, or 8
bytes signed integers depending on the manitudes, so we could save some
space for values ≥2³¹.)  But that seems a little overkill.

1 files changed, 2 insertions, 0 deletions

diff --git a/Changelog b/Changelog
index 3d8cd72..251d5dc 100644
--- a/Changelog
+++ b/Changelog
@@ -40,6 +40,8 @@ interimap (0.5) upstream;
    RFC 3501 sec. 6.3.4).
  - interimap: SQLite were not enforcing foreign key constraints (setting
    the 'foreign_keys' PRAGMA during a transaction is a documented no-op).
+ - interimap: fix handling of mod-sequence values greater or equal than
+   2 << 63.
 
  -- Guilhem Moulin <guilhem@fripost.org>  Fri, 10 May 2019 00:58:14 +0200