4b/39526b9b62f69fa1ae490cb195e89a438d0235

   1 Return-Path: <amdragon@mit.edu>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 47035431FD0\r
   6         for <notmuch@notmuchmail.org>; Mon, 20 Jun 2011 09:53:40 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id d7nUxEY62Oth for <notmuch@notmuchmail.org>;\r
  16         Mon, 20 Jun 2011 09:53:39 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU\r
  18         [18.7.68.35])\r
  19         by olra.theworths.org (Postfix) with ESMTP id CB431431FB6\r
  20         for <notmuch@notmuchmail.org>; Mon, 20 Jun 2011 09:53:39 -0700 (PDT)\r
  21 X-AuditID: 12074423-b7ce8ae000000a29-2e-4dff7b0c300e\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id BA.11.02601.C0B7FFD4; Mon, 20 Jun 2011 12:53:32 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p5KGrcZt010422; \r
  27         Mon, 20 Jun 2011 12:53:39 -0400\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p5KGrbiW018893\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Mon, 20 Jun 2011 12:53:38 -0400 (EDT)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1QYhj7-0000zr-Bm; Mon, 20 Jun 2011 12:53:29 -0400\r
  37 Date: Mon, 20 Jun 2011 12:53:29 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Sebastian Spaeth <Sebastian@sspaeth.de>\r
  40 Subject: Re: [python] segfaults at Message.get_date\r
  41 Message-ID: <20110620165329.GN16025@mit.edu>\r
  42 References: <20110616215439.GA26997@brick> <87boxxq833.fsf@SSpaeth.de>\r
  43         <20110617161024.GA8154@optimusprime> <87hb7n300m.fsf@SSpaeth.de>\r
  44         <87hb7m5f4s.fsf@gmail.com>\r
  45         <BANLkTik8ged+SoUQf5=x0m-CDC6rAKUoWQ@mail.gmail.com>\r
  46         <878vsxvu3x.fsf@SSpaeth.de>\r
  47 MIME-Version: 1.0\r
  48 Content-Type: text/plain; charset=us-ascii\r
  49 Content-Disposition: inline\r
  50 In-Reply-To: <878vsxvu3x.fsf@SSpaeth.de>\r
  51 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  52 X-Brightmail-Tracker:\r
  53  H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0eWp/u9rsKBNzOL6zZnMFrPmzGN0\r
  54         YPJ4tuoWs8fiL0tZApiiuGxSUnMyy1KL9O0SuDImf9vOVrCAt+Lco49MDYy3uboYOTkkBEwk\r
  55         ft6azwhhi0lcuLeerYuRi0NIYB+jxMz1O6GcDYwSazfuZoVwTjJJXLt7jRnCWcIocXzWJnaQ\r
  56         fhYBVYl5Px4wg9hsAhoS2/YvB5srIqAtcbRlByuIzSwgLfHtdzMTiC0sYCyxedFxsF5eAR2J\r
  57         1jaY3f8ZJZZPvcsMkRCUODnzCQtEs5bEjX8vgZo5wAYt/8cBEuYE2vVr4wGwmaICKhLX9rez\r
  58         TWAUmoWkexaS7lkI3QsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmunlZpbopaaUbmIEh7aL\r
  59         8g7GPweVDjEKcDAq8fA+Kv/vK8SaWFZcmXuIUZKDSUmUd18lUIgvKT+lMiOxOCO+qDQntfgQ\r
  60         owQHs5IIb/zjf75CvCmJlVWpRfkwKWkOFiVx3lxvoDaB9MSS1OzU1ILUIpisDAeHkgTv3xKg\r
  61         rGBRanpqRVpmTglCmomDE2Q4D9BwS5DFvMUFibnFmekQ+VOMilLivF5VIKNBEhmleXC9sNTz\r
  62         ilEc6BVh3iSQKh5g2oLrfgU0mAlo8P9XIFcXlyQipKQaGJdkLXoW2qh8YkIRu2WeT1Blp07q\r
  63         +npt+69914K1CvJnVu+59LklMDg38hNHiZzIyrkhyl9XhJzZdPW0StR6nRvLOv/lGmxyutWw\r
  64         l19oTUrf6uydNfdsVmxRnGhsOPNBwFb/GPfbvntXVmwx+XWt0DaA117mZgXr7N3cFsmahy7M\r
  65         /6e43yt+sRJLcUaioRZzUXEiAGnONK8YAwAA\r
  66 Cc: notmuch@notmuchmail.org\r
  67 X-BeenThere: notmuch@notmuchmail.org\r
  68 X-Mailman-Version: 2.1.13\r
  69 Precedence: list\r
  70 List-Id: "Use and development of the notmuch mail system."\r
  71         <notmuch.notmuchmail.org>\r
  72 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  73         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  74 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  75 List-Post: <mailto:notmuch@notmuchmail.org>\r
  76 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  77 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  78         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  79 X-List-Received-Date: Mon, 20 Jun 2011 16:53:40 -0000\r
  80 \r
  81 Quoth Sebastian Spaeth on Jun 20 at  9:29 am:\r
  82 > On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements <amdragon@mit.edu> wrote:\r
  83 > > A double will precisely represent integers up to 2^53, so this\r
  84 > > conversion shouldn't be a problem until the year 285422109 or so.\r
  85 > \r
  86 > But given that it works, is it actually necessary, that xapian\r
  87 > apparently pulls an int from the database, returns a std::string to\r
  88 > libnotmuch, which calls a helper function to unserialize it to a double\r
  89 > and casts it to time_t before handing it to the user how probably uses\r
  90 > it as a long?\r
  91 > \r
  92 > Can't we easily put in longs and get longs back?\r
  93 \r
  94 Xapian only knows about strings, so there has to be serialization\r
  95 somewhere and the serialized form has to have the same collation order\r
  96 as the numerical order of the original numbers.  You could do this by\r
  97 storing the bytes of the long in big-endian form, but that's basically\r
  98 what sortable_serialise does: roughly, the first byte stores the\r
  99 number of bits needed to represent the number, followed by enough\r
 100 bytes to hold those bits in big-endian.  Since POSIX permits a wide\r
 101 range of types to implement time_t, sortable_serialise also has the\r
 102 major advantage that it can handle any of them.  So, taking\r
 103 portability and time_t as assumptions, there are no unnecessary\r
 104 conversion steps here (and, really, it's just string->double->time_t\r
 105 on Linux and just string->time_t on a platform that uses floating\r
 106 point time_t's).\r
 107 \r
 108 Alternatively, notmuch could switch to using long instead of time_t\r
 109 for dates, but that seems like a lot of effort for little gain and\r
 110 results in portability friction whenever notmuch wants to use the\r
 111 standard C time API's.\r