Quoth Sebastian Spaeth on Jun 20 at 9:29 am: > On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements <amdragon at 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.