f9/9488bdc4a5f24e15ea61e944515c608f77ced1

   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 C5608429E25\r
   6         for <notmuch@notmuchmail.org>; Sun,  4 Dec 2011 08:39:51 -0800 (PST)\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 DltElyE36y+4 for <notmuch@notmuchmail.org>;\r
  16         Sun,  4 Dec 2011 08:39:51 -0800 (PST)\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 4B0F8429E21\r
  20         for <notmuch@notmuchmail.org>; Sun,  4 Dec 2011 08:39:51 -0800 (PST)\r
  21 X-AuditID: 12074423-b7f266d0000008b8-25-4edba25613d5\r
  22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  23         by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id B3.BB.02232.652ABDE4; Sun,  4 Dec 2011 11:39:50 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id pB4GdnYH013939; \r
  27         Sun, 4 Dec 2011 11:39:50 -0500\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 pB4GdmPS012528\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sun, 4 Dec 2011 11:39:49 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1RXF8B-0005zM-5j; Sun, 04 Dec 2011 11:41:35 -0500\r
  37 Date: Sun, 4 Dec 2011 11:41:34 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Jani Nikula <jani@nikula.org>\r
  40 Subject: Re: [PATCH v2 1/2] cli: introduce the concept of user defined hooks\r
  41 Message-ID: <20111204164134.GT16194@mit.edu>\r
  42 References:\r
  43  <7fbe6befcf31881a9bca672f55b93501249a220c.1322859389.git.jani@nikula.org>\r
  44         <6688b09fffa2a66b496af78008102f88ab4e9450.1322953841.git.jani@nikula.org>\r
  45         <20111204034210.GA16405@mit.edu> <87sjl0ldk0.fsf@nikula.org>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=us-ascii\r
  48 Content-Disposition: inline\r
  49 In-Reply-To: <87sjl0ldk0.fsf@nikula.org>\r
  50 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  51 X-Brightmail-Tracker:\r
  52  H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1g1bdNvP4Nh8bYum6c4W12/OZHZg\r
  53         8rh1/zW7x7NVt5gDmKK4bFJSczLLUov07RK4Mtr6zzIXTOaqWP77HlMD40/2LkZODgkBE4nG\r
  54         J/cYIWwxiQv31rOB2EIC+xglXrdadjFyAdnrGSW2TX7ODJE4wSTxcWs2RGIJo8TCM7fAEiwC\r
  55         KhK3/m8Gm8QmoCGxbf9yMFtEQFFi88n9YDazgLTEt9/NTCC2sICPRPfPXWBX8AroSMyb9owF\r
  56         YugjRonLK59AJQQlTs58wgLRrCVx499LoGYOsEHL/3GAhDmBds0+1Ax2gyjQDVNObmObwCg0\r
  57         C0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI108vNLNFLTSndxAgKanYX5R2M\r
  58         fw4qHWIU4GBU4uHNPHHLT4g1say4MvcQoyQHk5Iob+n8235CfEn5KZUZicUZ8UWlOanFhxgl\r
  59         OJiVRHj5UoFyvCmJlVWpRfkwKWkOFiVxXpmdDn5CAumJJanZqakFqUUwWRkODiUJ3nMLgRoF\r
  60         i1LTUyvSMnNKENJMHJwgw3mAhoPV8BYXJOYWZ6ZD5E8xKkqJ894ESQiAJDJK8+B6YUnnFaM4\r
  61         0CvCvGdBqniACQuu+xXQYCagwYqNN0AGlyQipKQaGM0ebbst9V7T4TznRgtnxs01Umomi+/z\r
  62         FXJK34jxlu978pQxOULK2u3d4SWcO/iD/vSwcLZ32tr/0P5r9FJNc0VumH6XbWdzwal0qa4t\r
  63         wm6n/m4tu3B1Q+PiIj2tD2vqTutei1UvsomcO53h2rkctoajWculmtZ/O3TngvMGJo3tv3fe\r
  64         O3FslxJLcUaioRZzUXEiAOez8ToVAwAA\r
  65 Cc: notmuch@notmuchmail.org\r
  66 X-BeenThere: notmuch@notmuchmail.org\r
  67 X-Mailman-Version: 2.1.13\r
  68 Precedence: list\r
  69 List-Id: "Use and development of the notmuch mail system."\r
  70         <notmuch.notmuchmail.org>\r
  71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  74 List-Post: <mailto:notmuch@notmuchmail.org>\r
  75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  78 X-List-Received-Date: Sun, 04 Dec 2011 16:39:51 -0000\r
  79 \r
  80 Quoth Jani Nikula on Dec 04 at  2:35 pm:\r
  81 > > > +int\r
  82 > > > +notmuch_run_hook (const char *db_path, const char *hook)\r
  83 > > > +{\r
  84 > > > +    char *hook_path;\r
  85 > > > +    int status = 0;\r
  86 > > \r
  87 > > You use status as both a notmuch_status_t and for generic C library\r
  88 > > results.  This seems a little weird.  You may or may not want to do\r
  89 > > anything about it.\r
  90 > \r
  91 > True, it's not consistent. I'll want to do something about it. I wonder\r
  92 > if it's worth returning anything other than ok/fail from this function\r
  93 > anyway.\r
  94 > \r
  95 > There seems to be some confusion in notmuch_status_t usage across\r
  96 > notmuch cli. Should notmuch cli return a notmuch_status_t as exit\r
  97 > status? It currently does at least in some cases, but it also returns\r
  98 > plain 1 too which is (unintentionally) NOTMUCH_STATUS_OUT_OF_MEMORY.\r
  99 > \r
 100 > Does it make sense for the cli to use the lib statuses internally\r
 101 > anyway; you wouldn't want to add new status codes to the lib just to be\r
 102 > able to use them in cli.\r
 103 \r
 104 I think the answer is that there's no good answer because error\r
 105 handling in C is so lame.  In this particular case, I'd say there's\r
 106 little point in distinguishing different errors (and especially no\r
 107 point in returning not-quite-appropriate status codes), so perhaps it\r
 108 should follow the 0/1 convention.\r