73/ec89a23233f0d15aceca876347350d34386eb6

   1 Return-Path: <jani@nikula.org>\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 A1C97431FC2\r
   6         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:32:01 -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.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[HTML_MESSAGE=0.001, 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 Pu6-Fo+6Z6Wd for <notmuch@notmuchmail.org>;\r
  16         Thu, 17 May 2012 09:32:01 -0700 (PDT)\r
  17 Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com\r
  18         [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id E639D431FAE\r
  21         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:32:00 -0700 (PDT)\r
  22 Received: by obbuo19 with SMTP id uo19so3102612obb.26\r
  23         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=google.com; s=20120113;\r
  26         h=mime-version:in-reply-to:references:date:message-id:subject:from:to\r
  27         :cc:content-type:x-gm-message-state;\r
  28         bh=fHo9KovhABXYVu3XD+A+GFUrZqRNqUHvOJIxDU+fhNQ=;\r
  29         b=O/rTGoCXh1FcZL6nlAIvQ8oqIIcb2nT1z4v2uw0o4X0LKUQ/2ptyQfG2GJXJmtw/s0\r
  30         jXsZskBPXvgr+jVvVo4DS4RM3bb2d+U/Eg14Tuud4589insFeL1yHrwjCVJCA34bSthL\r
  31         kFfRPjAsnzNqGVK4ZtEqHlPhMPl1idDYpqwqabjP17x4REikXfvTNEIegmPo9Z7EZ15b\r
  32         EBpcfo2OGhE/R/L0Jl9BrrVqi8hJEAYhZqDFdmHSyt7kKyg8X4IyqiWRhjGAd90M6/wa\r
  33         LlZpaVnUBzMLfcEks2yo0VjuarjR9/pPf/hsN38bZa8Wvx6gUw9yFLv6Q2bTiU5F632f\r
  34         rOIQ==\r
  35 MIME-Version: 1.0\r
  36 Received: by 10.182.167.68 with SMTP id zm4mr7178368obb.25.1337272319458; Thu,\r
  37         17 May 2012 09:31:59 -0700 (PDT)\r
  38 Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
  39 Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT)\r
  40 In-Reply-To: <877gwaeve1.fsf@servo.finestructure.net>\r
  41 References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
  42         <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
  43         <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
  44         <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
  45         <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
  46         <8762bvi70k.fsf@nikula.org>\r
  47         <877gwaeve1.fsf@servo.finestructure.net>\r
  48 Date: Thu, 17 May 2012 19:31:59 +0300\r
  49 Message-ID:\r
  50  <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
  51 Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
  52 From: Jani Nikula <jani@nikula.org>\r
  53 To: Jameson Graef Rollins <jrollins@finestructure.net>\r
  54 Content-Type: multipart/alternative; boundary=e89a8f83a5a191be2804c03df912\r
  55 X-Gm-Message-State:\r
  56  ALoCoQl2ZMcZRuDRBwGDM3va+hXYNjRJ0VQTIL5pVapQewHol8Hp1xySxCHpQjNfzEXGGTGexJyA\r
  57 Cc: Notmuch Mail <notmuch@notmuchmail.org>\r
  58 X-BeenThere: notmuch@notmuchmail.org\r
  59 X-Mailman-Version: 2.1.13\r
  60 Precedence: list\r
  61 List-Id: "Use and development of the notmuch mail system."\r
  62         <notmuch.notmuchmail.org>\r
  63 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  65 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  66 List-Post: <mailto:notmuch@notmuchmail.org>\r
  67 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  68 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  70 X-List-Received-Date: Thu, 17 May 2012 16:32:01 -0000\r
  71 \r
  72 --e89a8f83a5a191be2804c03df912\r
  73 Content-Type: text/plain; charset=UTF-8\r
  74 \r
  75 On May 17, 2012 5:26 PM, "Jameson Graef Rollins" <jrollins@finestructure.net>\r
  76 wrote:\r
  77 >\r
  78 > On Thu, May 17 2012, Jani Nikula <jani@nikula.org> wrote:\r
  79 > > On Thu, 17 May 2012, Jameson Graef Rollins <jrollins@finestructure.net>\r
  80 wrote:\r
  81 > >> This makes sure it has proper initialization values when it's created.\r
  82 > >\r
  83 > > Please don't do this. It's unnecessary; if one field is initialized with\r
  84 > > a designated initializer, the rest are initialized to zero (or NULL).\r
  85 >\r
  86 > It may be technically unnecessary, but why is that a reason to not do\r
  87 > it?  I intentionally did this to make it clear what the defaults are.\r
  88 > Otherwise the defaults are essentially undefined, which is not good.\r
  89 > Maybe the structure initializes to the correct defaults, but why count\r
  90 > on that when we can set them to the correct default, and have it clear\r
  91 > to readers of the code?\r
  92 \r
  93 The values are not undefined, they are properly initialized, and we can\r
  94 count on it. For sure, not maybe. If you want to explicitly set them for\r
  95 clarity, it's a matter of taste. Personally I find it too verbose, but then\r
  96 again notmuch code is generally fairly verbose. If you insist on it, please\r
  97 at least drop the extra temp crypto variable, and initialize the struct in\r
  98 one initializer.\r
  99 \r
 100 BR,\r
 101 Jani.\r
 102 \r
 103 >\r
 104 > jamie.\r
 105 \r
 106 --e89a8f83a5a191be2804c03df912\r
 107 Content-Type: text/html; charset=UTF-8\r
 108 Content-Transfer-Encoding: quoted-printable\r
 109 \r
 110 <p><br>\r
 111 On May 17, 2012 5:26 PM, &quot;Jameson Graef Rollins&quot; &lt;<a href=3D"m=\r
 112 ailto:jrollins@finestructure.net">jrollins@finestructure.net</a>&gt; wrote:=\r
 113 <br>\r
 114 &gt;<br>\r
 115 &gt; On Thu, May 17 2012, Jani Nikula &lt;<a href=3D"mailto:jani@nikula.org=\r
 116 ">jani@nikula.org</a>&gt; wrote:<br>\r
 117 &gt; &gt; On Thu, 17 May 2012, Jameson Graef Rollins &lt;<a href=3D"mailto:=\r
 118 jrollins@finestructure.net">jrollins@finestructure.net</a>&gt; wrote:<br>\r
 119 &gt; &gt;&gt; This makes sure it has proper initialization values when it&#=\r
 120 39;s created.<br>\r
 121 &gt; &gt;<br>\r
 122 &gt; &gt; Please don&#39;t do this. It&#39;s unnecessary; if one field is i=\r
 123 nitialized with<br>\r
 124 &gt; &gt; a designated initializer, the rest are initialized to zero (or NU=\r
 125 LL).<br>\r
 126 &gt;<br>\r
 127 &gt; It may be technically unnecessary, but why is that a reason to not do<=\r
 128 br>\r
 129 &gt; it? =C2=A0I intentionally did this to make it clear what the defaults =\r
 130 are.<br>\r
 131 &gt; Otherwise the defaults are essentially undefined, which is not good.<b=\r
 132 r>\r
 133 &gt; Maybe the structure initializes to the correct defaults, but why count=\r
 134 <br>\r
 135 &gt; on that when we can set them to the correct default, and have it clear=\r
 136 <br>\r
 137 &gt; to readers of the code?</p>\r
 138 <p>The values are not undefined, they are properly initialized, and we can =\r
 139 count on it. For sure, not maybe. If you want to explicitly set them for cl=\r
 140 arity, it&#39;s a matter of taste. Personally I find it too verbose, but th=\r
 141 en again notmuch code is generally fairly verbose. If you insist on it, ple=\r
 142 ase at least drop the extra temp crypto variable, and initialize the struct=\r
 143  in one initializer.</p>\r
 144 \r
 145 <p>BR,<br>\r
 146 Jani.<br></p>\r
 147 <p>&gt;<br>\r
 148 &gt; jamie.<br>\r
 149 </p>\r
 150 \r
 151 --e89a8f83a5a191be2804c03df912--\r