Re: [PATCH 4/6] cli: intialize crypto structure in show and reply

diff --git a/d6/e715526d2fcd39a9661c3d1fe9cab4edc5424d b/d6/e715526d2fcd39a9661c3d1fe9cab4edc5424d
new file mode 100644 (file)
index 0000000..33bbfd5
--- /dev/null
+++ b/d6/e715526d2fcd39a9661c3d1fe9cab4edc5424d
@@ -0,0 +1,102 @@
+Return-Path: <tomi.ollila@iki.fi>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id B8BAF431FB6\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 23:59:19 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id uBdPgxWwq+Wi for <notmuch@notmuchmail.org>;\r
+       Thu, 17 May 2012 23:59:18 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+       by olra.theworths.org (Postfix) with ESMTP id 7122A431FAE\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 23:59:18 -0700 (PDT)\r
+Received: by guru.guru-group.fi (Postfix, from userid 501)\r
+       id 3E18D100639; Fri, 18 May 2012 09:59:27 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
+       Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
+In-Reply-To: <4FB572DA.8040906@fifthhorseman.net>\r
+References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
+       <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
+       <8762bvi70k.fsf@nikula.org>\r
+       <877gwaeve1.fsf@servo.finestructure.net>\r
+       <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
+       <87aa16daeq.fsf@servo.finestructure.net>\r
+       <4FB572DA.8040906@fifthhorseman.net>\r
+User-Agent: Notmuch/0.13~rc1+23~gefd2384 (http://notmuchmail.org) Emacs/23.1.1\r
+       (x86_64-redhat-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+       $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+       !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Fri, 18 May 2012 09:59:27 +0300\r
+Message-ID: <m28vgqdlf4.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 18 May 2012 06:59:19 -0000\r
+\r
+On Fri, May 18 2012, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
+\r
+>\r
+> The real tradeoff in this choice is whether we prefer:\r
+>\r
+>  a) more compact code to facilitate quick reading by experts\r
+>\r
+>    or\r
+>\r
+>  b) more verbose code to facilitate comprehension by the non-expert.\r
+>\r
+> I started this discussion leaning strongly toward the (b) perspective.\r
+> But now that i know the relevant bits of the standard, i can sympathize\r
+> with the (a) perspective as well :P\r
+>\r
+> Overall, i think i'm still in the (b) camp.  But i think it's more\r
+> important that we don't allow dithering over this issue to prevent the\r
+> inclusion of this patch series, which is a step in the right direction\r
+> for handling S/MIME messages as well as PGP/MIME.\r
+\r
+I also think it is good to see explicit initializations when those aren't\r
+needed but clarifies the code. After all it doesn't generate any extra\r
+code to the target module. Also the &(params->crypto) is good from\r
+clarification point of view.\r
+\r
+Austin's .crypto { ... } initialization looks good & clear; In case there\r
+will be new version of this patch series I'd like to see that used...\r
+\r
+>      --dkg\r
+>\r
+> PS gcc's -pedantic argument provides the following warning:\r
+>\r
+>  error: ISO C90 forbids specifying subobject to initialize\r
+>\r
+> So we probably want to specify -std=c99 at least to ensure our choice of\r
+> subobject initialization is respected.\r
+\r
+In order to do that id:"cover.1325977940.git.jani@nikula.org" needs to\r
+be applied (and probably rebased).\r
+\r
+> [0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf\r
+\r
+Tomi\r