Re: [PATCH 4/6] cli: intialize crypto structure in show and reply
authorJani Nikula <jani@nikula.org>
Fri, 18 May 2012 08:20:43 +0000 (08:20 +0000)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:47:13 +0000 (09:47 -0800)
dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 [new file with mode: 0644]

diff --git a/dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 b/dd/827a27fa2ed75c7c476b8fae7778ca503bcf57
new file mode 100644 (file)
index 0000000..f9bea75
--- /dev/null
@@ -0,0 +1,142 @@
+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 30240431FB6\r
+       for <notmuch@notmuchmail.org>; Fri, 18 May 2012 01:20:55 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[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 VZ+HLLaqsfWl for <notmuch@notmuchmail.org>;\r
+       Fri, 18 May 2012 01:20:50 -0700 (PDT)\r
+Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com\r
+       [209.85.216.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 883CE431FAE\r
+       for <notmuch@notmuchmail.org>; Fri, 18 May 2012 01:20:50 -0700 (PDT)\r
+Received: by qadb17 with SMTP id b17so7457069qad.5\r
+       for <notmuch@notmuchmail.org>; Fri, 18 May 2012 01:20:48 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=google.com; s=20120113;\r
+       h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
+       :mime-version:content-type:x-gm-message-state;\r
+       bh=PLLeUELAknwX/a/cnA+c9djTrynuotHr/Xjtt40wX3Y=;\r
+       b=Km96I0W2cXXAoaS7Wf5M8MQetNX/XOoVBkQNNcHBYJJfk/AefLc49wNTgj0G4pHl+B\r
+       /Q5Vi8JPtYkJbEob7vZaJO/QJ4EEZiwUSXYIUqjk0zHnurgYG+8iqDsljgWkU8UMYdNE\r
+       w+e/2w1XQqvPJXxe40lVI2N89vMAEHwkOrRZKoagBIK64QxfAPeccInggXanS8ubXA0a\r
+       kuZe9i4W5AM8+v+P0+mZvO4ODLQsPPWviH8auEPRo84LxCpE7r7/xGbA6UCYpsuhegoa\r
+       amVEMOx1Ut/oqRCA3TVJmWU77fNxm1z7/DqrdrDDTlUYAFkr8lbdRwSL1mX9bF+VCiyv\r
+       d2hQ==\r
+Received: by 10.224.175.69 with SMTP id w5mr21419318qaz.49.1337329248767;\r
+       Fri, 18 May 2012 01:20:48 -0700 (PDT)\r
+Received: from localhost ([92.243.24.172]) by mx.google.com with ESMTPS id\r
+       ch15sm19706657qab.18.2012.05.18.01.20.47\r
+       (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 01:20:48 -0700 (PDT)\r
+From: Jani Nikula <jani@nikula.org>\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+9~ga1668d0 (http://notmuchmail.org) Emacs/23.1.1\r
+       (i686-pc-linux-gnu)\r
+Date: Fri, 18 May 2012 08:20:43 +0000\r
+Message-ID: <87txzdew84.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Gm-Message-State:\r
+ ALoCoQl4+24lIVjmDA/WcYIBeK8XYhBSm48ywFydXRRG0f/enPEPZ6+xHQP1eg8UoINn4eaMtilA\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 08:20:55 -0000\r
+\r
+\r
+*sigh* I'm failing to detach myself from this conversation. :(\r
+\r
+On Thu, 17 May 2012, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
+> I don't think it's an assumption -- Jani is probably relying on the C\r
+> standard. Consider, for example, C99 [0]'s section 6.7.8.19, which says:\r
+\r
+Thanks for digging up the references.\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
+We have -Wextra, which enables -Wmissing-field-initializers, which\r
+requires us to use full initialization of struct fields when doing\r
+regular, non-designated initialization. The point is that you might\r
+introduce subtle bugs if you added new struct fields and forgot to check\r
+the initializations. (This is why we have e.g. { 0, 0, 0, 0, 0 } instead\r
+of just { 0 } in the initialization of notmuch_opt_desc_t arrays.)\r
+\r
+IMHO the whole point of designated initializers is that the\r
+initialization is not vulnerable to struct changes, and you can pick\r
+which fields you choose to initialize explicitly. Also, it has the added\r
+benefit of documenting the fields that are initialized, without having\r
+to look at the struct definition.\r
+\r
+Do we now want to initialize all struct fields explicitly, everywhere,\r
+even when using designated initializers? Isn't that the question then?\r
+Won't that maintain and promote the misconception that explicit\r
+initialization is required, when it's really not, failing to educate the\r
+non-experts and planting a seed of doubt in the experts...?\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
+It's not always clear whether something is a matter of taste, style, or\r
+language paradigm. If it feels like a paradigm, sticking with it\r
+ultimately benefits *both* perspectives.\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
+Agreed.\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
+Unfortunately, the notmuch code base uses mixed standards, due to GCC\r
+being so lax about it. Anything -pedantic produces warnings:\r
+id:"cover.1325977940.git.jani@nikula.org". You may also want to try\r
+clang to get better warnings.\r
+\r
+\r
+BR,\r
+Jani.\r