2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d

   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 30BA6431FAF\r
   6         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 14:51:32 -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 kBi4xs1QyYN1 for <notmuch@notmuchmail.org>;\r
  16         Thu, 17 May 2012 14:51:31 -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 632E3431FAE\r
  19         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 14:51:31 -0700 (PDT)\r
  20 Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98])\r
  21         by che.mayfirst.org (Postfix) with ESMTPSA id 79C7EF970\r
  22         for <notmuch@notmuchmail.org>; Thu, 17 May 2012 17:51:29 -0400 (EDT)\r
  23 Message-ID: <4FB572DA.8040906@fifthhorseman.net>\r
  24 Date: Thu, 17 May 2012 17:51:22 -0400\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 User-Agent: Mozilla/5.0 (X11; Linux i686;\r
  27         rv:10.0.3) Gecko/20120329 Icedove/10.0.3\r
  28 MIME-Version: 1.0\r
  29 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  30 Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply\r
  31 References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net>\r
  32         <1337205359-2444-2-git-send-email-jrollins@finestructure.net>\r
  33         <1337205359-2444-3-git-send-email-jrollins@finestructure.net>\r
  34         <1337205359-2444-4-git-send-email-jrollins@finestructure.net>\r
  35         <1337205359-2444-5-git-send-email-jrollins@finestructure.net>\r
  36         <8762bvi70k.fsf@nikula.org>\r
  37         <877gwaeve1.fsf@servo.finestructure.net>\r
  38         <CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>\r
  39         <87aa16daeq.fsf@servo.finestructure.net>\r
  40 In-Reply-To: <87aa16daeq.fsf@servo.finestructure.net>\r
  41 X-Enigmail-Version: 1.4.1\r
  42 Content-Type: multipart/signed; micalg=pgp-sha512;\r
  43         protocol="application/pgp-signature";\r
  44         boundary="------------enig211B718926B718A80E8BA9D1"\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  49 List-Id: "Use and development of the notmuch mail system."\r
  50         <notmuch.notmuchmail.org>\r
  51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  54 List-Post: <mailto:notmuch@notmuchmail.org>\r
  55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  58 X-List-Received-Date: Thu, 17 May 2012 21:51:32 -0000\r
  59 \r
  60 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)\r
  61 --------------enig211B718926B718A80E8BA9D1\r
  62 Content-Type: text/plain; charset=UTF-8\r
  63 Content-Transfer-Encoding: quoted-printable\r
  64 \r
  65 On 05/17/2012 12:45 PM, Jameson Graef Rollins wrote:\r
  66 > I want them explicitly set for clarity, as well as safety.  Code is\r
  67 > meant to be read by humans, not computers. =20\r
  68 \r
  69 I sympathize with this sentiment.\r
  70 \r
  71 > It's much safer to explicitly set them to what you want\r
  72 > them to be rather than just assume they'll be set correctly.\r
  73 \r
  74 I don't think it's an assumption -- Jani is probably relying on the C\r
  75 standard. Consider, for example, C99 [0]'s section 6.7.8.19, which says:\r
  76 \r
  77   all subobjects that are not initialized explicitly shall be\r
  78   initialized implicitly the same as objects that have static\r
  79   storage duration.\r
  80 \r
  81 the latter clause references 6.7.8.10, which says:\r
  82 \r
  83    If an object that has static storage duration is not\r
  84    initialized explicitly, then:\r
  85      =E2=80=94 if it has pointer type, it is initialized to a null pointe=\r
  86 r;\r
  87      =E2=80=94 if it has arithmetic type, it is initialized to (positive =\r
  88 or\r
  89        unsigned) zero;\r
  90      =E2=80=94 if it is an aggregate, every member is initialized\r
  91        (recursively) according to these rules;\r
  92 \r
  93 So it's not just "an assumption", it's a guarantee from the underlying\r
  94 language standard.\r
  95 \r
  96 That said, it's a guarantee i was unaware of until i researched this.\r
  97 I'm certainly not a C guru, but i've internalized a fair amount of C's\r
  98 rules and structure and i'd never heard of this\r
  99 subobject-default-initialization-when-other-subobjects-are-initialized\r
 100 rule before.   If i'd seen the uninitialized members of the struct, and\r
 101 that they were being used without explicit initialization, i would have\r
 102 had to do a bit of digging to understand what's happening.\r
 103 \r
 104 The real tradeoff in this choice is whether we prefer:\r
 105 \r
 106  a) more compact code to facilitate quick reading by experts\r
 107 \r
 108    or\r
 109 \r
 110  b) more verbose code to facilitate comprehension by the non-expert.\r
 111 \r
 112 I started this discussion leaning strongly toward the (b) perspective.\r
 113 But now that i know the relevant bits of the standard, i can sympathize\r
 114 with the (a) perspective as well :P\r
 115 \r
 116 Overall, i think i'm still in the (b) camp.  But i think it's more\r
 117 important that we don't allow dithering over this issue to prevent the\r
 118 inclusion of this patch series, which is a step in the right direction\r
 119 for handling S/MIME messages as well as PGP/MIME.\r
 120 \r
 121         --dkg\r
 122 \r
 123 PS gcc's -pedantic argument provides the following warning:\r
 124 \r
 125  error: ISO C90 forbids specifying subobject to initialize\r
 126 \r
 127 So we probably want to specify -std=3Dc99 at least to ensure our choice o=\r
 128 f\r
 129 subobject initialization is respected.\r
 130 \r
 131 [0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf\r
 132 \r
 133 \r
 134 --------------enig211B718926B718A80E8BA9D1\r
 135 Content-Type: application/pgp-signature; name="signature.asc"\r
 136 Content-Description: OpenPGP digital signature\r
 137 Content-Disposition: attachment; filename="signature.asc"\r
 138 \r
 139 -----BEGIN PGP SIGNATURE-----\r
 140 Version: GnuPG v1.4.12 (GNU/Linux)\r
 141 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\r
 142 \r
 143 iQJ8BAEBCgBmBQJPtXLaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
 144 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD\r
 145 Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpQO4P/246CcM6ig/nB2mkmephJFTt\r
 146 MJ/x5P2SCPwhCx8DfVyHco1e8WZgk/X3Q5+bHVClSpJZrsydt3qSsOfU/KG6S4kr\r
 147 M6DrGv8UUpeBDNH+x5K0AW/27A9InmdEpGBeCizGyIRue/R8PU4+xgc8hox3z43r\r
 148 oMuBa+VOmHmlv4dPCR6XvsxWWmOrHH/CawHD1GX1bLe6XSKnAxURgWmrPHQA+PIa\r
 149 M4otEwmFGtVr2aMO7N6OyzwJ92RP40Z8Y+oGj+4q9eVQiiJo/LwAUgLjRWhwmLM0\r
 150 YMzNcFIE0sv9CQKyFziIN7NfIpunDvq2rxtEVuR1fFiA6fdIoV4JGyJaqvIkxkwW\r
 151 jpOwcn3vhCzAbsLLWe+O/1/fvF8h5i52IgXm3u8HkXCixY6La3ah8J5ZY9fZd2PT\r
 152 ETrmy2GCK8+GRLEAjHfbLXPubTE6KIx3kGqP63Uohi9cdAU9fLZOzm9Z6l0pdq1s\r
 153 K1AobyTdKmdwhd8FWWArLfaqxz3l/09bQCYS/h9wOzfzmMuoT00UDsDdBNBRUHSc\r
 154 8j/Ouj9C0EzpTTzMidfgcColwugJBhaeizlaSJDWibLDlrQlu6nxlxZCas9izSqo\r
 155 6UDqv7m/vaCNAGwocoCmfFZkMBEQmrsuNtA1iJck270czAJURVFRHgC+sbXTxunH\r
 156 rccpoLAnGEcTUmfqYqj2\r
 157 =eOSi\r
 158 -----END PGP SIGNATURE-----\r
 159 \r
 160 --------------enig211B718926B718A80E8BA9D1--\r