Re: [python] segfaults at Message.get_date

[Austin Clements <amdragon@MIT.EDU>]

Quoth Sebastian Spaeth on Jun 20 at  9:29 am:
> On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > A double will precisely represent integers up to 2^53, so this
> > conversion shouldn't be a problem until the year 285422109 or so.
> 
> But given that it works, is it actually necessary, that xapian
> apparently pulls an int from the database, returns a std::string to
> libnotmuch, which calls a helper function to unserialize it to a double
> and casts it to time_t before handing it to the user how probably uses
> it as a long?
> 
> Can't we easily put in longs and get longs back?

Xapian only knows about strings, so there has to be serialization
somewhere and the serialized form has to have the same collation order
as the numerical order of the original numbers.  You could do this by
storing the bytes of the long in big-endian form, but that's basically
what sortable_serialise does: roughly, the first byte stores the
number of bits needed to represent the number, followed by enough
bytes to hold those bits in big-endian.  Since POSIX permits a wide
range of types to implement time_t, sortable_serialise also has the
major advantage that it can handle any of them.  So, taking
portability and time_t as assumptions, there are no unnecessary
conversion steps here (and, really, it's just string->double->time_t
on Linux and just string->time_t on a platform that uses floating
point time_t's).

Alternatively, notmuch could switch to using long instead of time_t
for dates, but that seems like a lot of effort for little gain and
results in portability friction whenever notmuch wants to use the
standard C time API's.