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

diff --git a/73/ec89a23233f0d15aceca876347350d34386eb6 b/73/ec89a23233f0d15aceca876347350d34386eb6
new file mode 100644 (file)
index 0000000..cd81945
--- /dev/null
+++ b/73/ec89a23233f0d15aceca876347350d34386eb6
@@ -0,0 +1,151 @@
+Return-Path: <jani@nikula.org>\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 A1C97431FC2\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:32:01 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.699\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
+       tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Pu6-Fo+6Z6Wd for <notmuch@notmuchmail.org>;\r
+       Thu, 17 May 2012 09:32:01 -0700 (PDT)\r
+Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com\r
+       [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id E639D431FAE\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:32:00 -0700 (PDT)\r
+Received: by obbuo19 with SMTP id uo19so3102612obb.26\r
+       for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=google.com; s=20120113;\r
+       h=mime-version:in-reply-to:references:date:message-id:subject:from:to\r
+       :cc:content-type:x-gm-message-state;\r
+       bh=fHo9KovhABXYVu3XD+A+GFUrZqRNqUHvOJIxDU+fhNQ=;\r
+       b=O/rTGoCXh1FcZL6nlAIvQ8oqIIcb2nT1z4v2uw0o4X0LKUQ/2ptyQfG2GJXJmtw/s0\r
+       jXsZskBPXvgr+jVvVo4DS4RM3bb2d+U/Eg14Tuud4589insFeL1yHrwjCVJCA34bSthL\r
+       kFfRPjAsnzNqGVK4ZtEqHlPhMPl1idDYpqwqabjP17x4REikXfvTNEIegmPo9Z7EZ15b\r
+       EBpcfo2OGhE/R/L0Jl9BrrVqi8hJEAYhZqDFdmHSyt7kKyg8X4IyqiWRhjGAd90M6/wa\r
+       LlZpaVnUBzMLfcEks2yo0VjuarjR9/pPf/hsN38bZa8Wvx6gUw9yFLv6Q2bTiU5F632f\r
+       rOIQ==\r
+MIME-Version: 1.0\r
+Received: by 10.182.167.68 with SMTP id zm4mr7178368obb.25.1337272319458; Thu,\r
+       17 May 2012 09:31:59 -0700 (PDT)\r
+Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
+Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
+In-Reply-To: <877gwaeve1.fsf@servo.finestructure.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
+Date: Thu, 17 May 2012 19:31:59 +0300\r
+Message-ID:\r
+ <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
+Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Jameson Graef Rollins <jrollins@finestructure.net>\r
+Content-Type: multipart/alternative; boundary=e89a8f83a5a191be2804c03df912\r
+X-Gm-Message-State:\r
+ ALoCoQl2ZMcZRuDRBwGDM3va+hXYNjRJ0VQTIL5pVapQewHol8Hp1xySxCHpQjNfzEXGGTGexJyA\r
+Cc: Notmuch Mail <notmuch@notmuchmail.org>\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: Thu, 17 May 2012 16:32:01 -0000\r
+\r
+--e89a8f83a5a191be2804c03df912\r
+Content-Type: text/plain; charset=UTF-8\r
+\r
+On May 17, 2012 5:26 PM, "Jameson Graef Rollins" <jrollins@finestructure.net>\r
+wrote:\r
+>\r
+> On Thu, May 17 2012, Jani Nikula <jani@nikula.org> wrote:\r
+> > On Thu, 17 May 2012, Jameson Graef Rollins <jrollins@finestructure.net>\r
+wrote:\r
+> >> This makes sure it has proper initialization values when it's created.\r
+> >\r
+> > Please don't do this. It's unnecessary; if one field is initialized with\r
+> > a designated initializer, the rest are initialized to zero (or NULL).\r
+>\r
+> It may be technically unnecessary, but why is that a reason to not do\r
+> it?  I intentionally did this to make it clear what the defaults are.\r
+> Otherwise the defaults are essentially undefined, which is not good.\r
+> Maybe the structure initializes to the correct defaults, but why count\r
+> on that when we can set them to the correct default, and have it clear\r
+> to readers of the code?\r
+\r
+The values are not undefined, they are properly initialized, and we can\r
+count on it. For sure, not maybe. If you want to explicitly set them for\r
+clarity, it's a matter of taste. Personally I find it too verbose, but then\r
+again notmuch code is generally fairly verbose. If you insist on it, please\r
+at least drop the extra temp crypto variable, and initialize the struct in\r
+one initializer.\r
+\r
+BR,\r
+Jani.\r
+\r
+>\r
+> jamie.\r
+\r
+--e89a8f83a5a191be2804c03df912\r
+Content-Type: text/html; charset=UTF-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+<p><br>\r
+On May 17, 2012 5:26 PM, &quot;Jameson Graef Rollins&quot; &lt;<a href=3D"m=\r
+ailto:jrollins@finestructure.net">jrollins@finestructure.net</a>&gt; wrote:=\r
+<br>\r
+&gt;<br>\r
+&gt; On Thu, May 17 2012, Jani Nikula &lt;<a href=3D"mailto:jani@nikula.org=\r
+">jani@nikula.org</a>&gt; wrote:<br>\r
+&gt; &gt; On Thu, 17 May 2012, Jameson Graef Rollins &lt;<a href=3D"mailto:=\r
+jrollins@finestructure.net">jrollins@finestructure.net</a>&gt; wrote:<br>\r
+&gt; &gt;&gt; This makes sure it has proper initialization values when it&#=\r
+39;s created.<br>\r
+&gt; &gt;<br>\r
+&gt; &gt; Please don&#39;t do this. It&#39;s unnecessary; if one field is i=\r
+nitialized with<br>\r
+&gt; &gt; a designated initializer, the rest are initialized to zero (or NU=\r
+LL).<br>\r
+&gt;<br>\r
+&gt; It may be technically unnecessary, but why is that a reason to not do<=\r
+br>\r
+&gt; it? =C2=A0I intentionally did this to make it clear what the defaults =\r
+are.<br>\r
+&gt; Otherwise the defaults are essentially undefined, which is not good.<b=\r
+r>\r
+&gt; Maybe the structure initializes to the correct defaults, but why count=\r
+<br>\r
+&gt; on that when we can set them to the correct default, and have it clear=\r
+<br>\r
+&gt; to readers of the code?</p>\r
+<p>The values are not undefined, they are properly initialized, and we can =\r
+count on it. For sure, not maybe. If you want to explicitly set them for cl=\r
+arity, it&#39;s a matter of taste. Personally I find it too verbose, but th=\r
+en again notmuch code is generally fairly verbose. If you insist on it, ple=\r
+ase at least drop the extra temp crypto variable, and initialize the struct=\r
+ in one initializer.</p>\r
+\r
+<p>BR,<br>\r
+Jani.<br></p>\r
+<p>&gt;<br>\r
+&gt; jamie.<br>\r
+</p>\r
+\r
+--e89a8f83a5a191be2804c03df912--\r