88/ba12197379b150c03a08ad83d2e213bf0cd010

   1 Return-Path: <dkg@fifthhorseman.net>\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 39777431FB6\r
   6         for <notmuch@notmuchmail.org>; Fri, 18 May 2012 10:10:06 -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\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         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 NWn-R6lopsqT for <notmuch@notmuchmail.org>;\r
  16         Fri, 18 May 2012 10:10:05 -0700 (PDT)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 83284431FAE\r
  19         for <notmuch@notmuchmail.org>; Fri, 18 May 2012 10:10:05 -0700 (PDT)\r
  20 Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net\r
  21         [216.254.70.154])\r
  22         by che.mayfirst.org (Postfix) with ESMTPSA id 08889F970\r
  23         for <notmuch@notmuchmail.org>; Fri, 18 May 2012 13:10:03 -0400 (EDT)\r
  24 Message-ID: <4FB68262.5010408@fifthhorseman.net>\r
  25 Date: Fri, 18 May 2012 13:09:54 -0400\r
  26 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  27 User-Agent: Mozilla/5.0 (X11; Linux i686;\r
  28         rv:10.0.3) Gecko/20120329 Icedove/10.0.3\r
  29 MIME-Version: 1.0\r
  30 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
  32 References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
  33         <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
  34         <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
  35         <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
  36         <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
  37         <8762bvi70k.fsf@nikula.org>\r
  38         <877gwaeve1.fsf@servo.finestructure.net>\r
  39         <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
  40         <87aa16daeq.fsf@servo.finestructure.net>\r
  41         <4FB572DA.8040906@fifthhorseman.net> <87txzdew84.fsf@nikula.org>\r
  42 In-Reply-To: <87txzdew84.fsf@nikula.org>\r
  43 X-Enigmail-Version: 1.4.1\r
  44 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  45         protocol="application/pgp-signature";\r
  46         boundary="------------enigCD3B1D6B7D91068EB0EB744D"\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.13\r
  49 Precedence: list\r
  50 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  51 List-Id: "Use and development of the notmuch mail system."\r
  52         <notmuch.notmuchmail.org>\r
  53 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  55 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  56 List-Post: <mailto:notmuch@notmuchmail.org>\r
  57 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  58 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  60 X-List-Received-Date: Fri, 18 May 2012 17:10:06 -0000\r
  61 \r
  62 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  63 --------------enigCD3B1D6B7D91068EB0EB744D\r
  64 Content-Type: text/plain; charset=UTF-8\r
  65 Content-Transfer-Encoding: quoted-printable\r
  66 \r
  67 On 05/18/2012 04:20 AM, Jani Nikula wrote:\r
  68 > We have -Wextra, which enables -Wmissing-field-initializers, which\r
  69 > requires us to use full initialization of struct fields when doing\r
  70 > regular, non-designated initialization. The point is that you might\r
  71 > introduce subtle bugs if you added new struct fields and forgot to chec=\r
  72 k\r
  73 > the initializations. (This is why we have e.g. { 0, 0, 0, 0, 0 } instea=\r
  74 d\r
  75 > of just { 0 } in the initialization of notmuch_opt_desc_t arrays.)\r
  76 \r
  77 i think we can agree that this is the right choice.  We might even want\r
  78 to discourage non-designated initializations entirely.\r
  79 \r
  80 > IMHO the whole point of designated initializers is that the\r
  81 > initialization is not vulnerable to struct changes, and you can pick\r
  82 > which fields you choose to initialize explicitly. Also, it has the adde=\r
  83 d\r
  84 > benefit of documenting the fields that are initialized, without having\r
  85 > to look at the struct definition.\r
  86 \r
  87 Agreed.\r
  88 \r
  89 > Do we now want to initialize all struct fields explicitly, everywhere,\r
  90 > even when using designated initializers? Isn't that the question then?\r
  91 \r
  92 I'm not sure it has to be this dramatic and "all or nothing".  For\r
  93 example, it could be reasonable to explicitly initialize some subobjects\r
  94 and not others.  For example, the notmuch_crypto_t jamie is proposing\r
  95 would effectively encode the default setting for the --verify and\r
  96 --decrypt flags.  I could see wanting to explicitly initialize those\r
  97 default policy choices, even if they happen to be identical to the\r
  98 implicit "zero"ing.\r
  99 \r
 100 > Won't that maintain and promote the misconception that explicit\r
 101 > initialization is required, when it's really not, failing to educate th=\r
 102 e\r
 103 > non-experts and planting a seed of doubt in the experts...?\r
 104 \r
 105 i see your point here, which is why i'm not arguing that all subobjects\r
 106 need to be explicitly initialized all the time.\r
 107 \r
 108 > It's not always clear whether something is a matter of taste, style, or=\r
 109 \r
 110 > language paradigm. If it feels like a paradigm, sticking with it\r
 111 > ultimately benefits *both* perspectives.\r
 112 \r
 113 yep, understood.\r
 114 \r
 115         --dkg\r
 116 \r
 117 \r
 118 --------------enigCD3B1D6B7D91068EB0EB744D\r
 119 Content-Type: application/pgp-signature; name="signature.asc"\r
 120 Content-Description: OpenPGP digital signature\r
 121 Content-Disposition: attachment; filename="signature.asc"\r
 122 \r
 123 -----BEGIN PGP SIGNATURE-----\r
 124 Version: GnuPG v1.4.12 (GNU/Linux)\r
 125 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 126 \r
 127 iQJ8BAEBCgBmBQJPtoJoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 128 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
 129 Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznprlQQAJZm0916WkpKy1xSzXu1UlEJ\r
 130 4L1HSEf27PhnF09cwM0acCjsAYMFKC2ts9semIrKujU68OwVNKauAyMQ8FgDc7n0\r
 131 yNPfz4PjvifTNpDJkUlryS4wSUVtAv6RUVei0QnjmpzR3EWsXZ3Xs+XMp/MC8mt9\r
 132 VqNu7HRFBa/0u7A6WMd16Yy5PpYkT/EkaS3d+Y1LjcPhVXBN0pVYfQiRE5Xdt7KO\r
 133 kFC17xhsgYC70h0PQfjCLwbj9u7yew+59R3wMU0H+cWYvFXfeX5dOjYjUluV/jSB\r
 134 sEwkCmC9YHWzZELLv0BzdoXnidfUMf7yUbJoHLYTyKM//lcvuJc+Sp3WRljzxKiQ\r
 135 JmPekHlbNIoMmFMobwmE7MpRjcoxB7sG2bp318FbFRO0I2py8ZbQGWfgpVaZ55JO\r
 136 HnLpQ4Jn+aVeL1K9a4uWhzI2ONS1ygWbv2I1v7I01xgqNEe54rk3o9UQjYq+en/B\r
 137 8xp9HnIRdMgtRKFQnS1XzEZMTN7HSReCQscbCv5dIMCXsdoqDvJulXWKrIvpaXI3\r
 138 2zFRHkV42AsWRsu4tDtP87q1G/xEHSbbU2AbOJolXrgxfowvv/d6h5kkvfAH8s7U\r
 139 SifvEQn/FdEy7jZqjPNWu9t4ipYS+/XBkQsf7szQre3bbXV2JmHGFOFzIGpvGKed\r
 140 xRI1B1/LlSGw/52duuWE\r
 141 =uptl\r
 142 -----END PGP SIGNATURE-----\r
 143 \r
 144 --------------enigCD3B1D6B7D91068EB0EB744D--\r