From 6b8fd8abe273e14767ab774ab3f59b5e90fe0379 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Fri, 18 May 2012 17:51:22 +2000 Subject: [PATCH] Re: [PATCH 4/6] cli: intialize crypto structure in show and reply --- 2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d | 160 ++++++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d diff --git a/2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d b/2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d new file mode 100644 index 000000000..39ee0898a --- /dev/null +++ b/2e/28e22f68e15ac5689ec4e49aa43e2e8e3d1c8d @@ -0,0 +1,160 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 30BA6431FAF + for ; Thu, 17 May 2012 14:51:32 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id kBi4xs1QyYN1 for ; + Thu, 17 May 2012 14:51:31 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) + by olra.theworths.org (Postfix) with ESMTP id 632E3431FAE + for ; Thu, 17 May 2012 14:51:31 -0700 (PDT) +Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) + by che.mayfirst.org (Postfix) with ESMTPSA id 79C7EF970 + for ; Thu, 17 May 2012 17:51:29 -0400 (EDT) +Message-ID: <4FB572DA.8040906@fifthhorseman.net> +Date: Thu, 17 May 2012 17:51:22 -0400 +From: Daniel Kahn Gillmor +User-Agent: Mozilla/5.0 (X11; Linux i686; + rv:10.0.3) Gecko/20120329 Icedove/10.0.3 +MIME-Version: 1.0 +To: Notmuch Mail +Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply +References: <1337205359-2444-1-git-send-email-jrollins@finestructure.net> + <1337205359-2444-2-git-send-email-jrollins@finestructure.net> + <1337205359-2444-3-git-send-email-jrollins@finestructure.net> + <1337205359-2444-4-git-send-email-jrollins@finestructure.net> + <1337205359-2444-5-git-send-email-jrollins@finestructure.net> + <8762bvi70k.fsf@nikula.org> + <877gwaeve1.fsf@servo.finestructure.net> + + <87aa16daeq.fsf@servo.finestructure.net> +In-Reply-To: <87aa16daeq.fsf@servo.finestructure.net> +X-Enigmail-Version: 1.4.1 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; + boundary="------------enig211B718926B718A80E8BA9D1" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +Reply-To: notmuch +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Thu, 17 May 2012 21:51:32 -0000 + +This is an OpenPGP/MIME signed message (RFC 2440 and 3156) +--------------enig211B718926B718A80E8BA9D1 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +On 05/17/2012 12:45 PM, Jameson Graef Rollins wrote: +> I want them explicitly set for clarity, as well as safety. Code is +> meant to be read by humans, not computers. =20 + +I sympathize with this sentiment. + +> It's much safer to explicitly set them to what you want +> them to be rather than just assume they'll be set correctly. + +I don't think it's an assumption -- Jani is probably relying on the C +standard. Consider, for example, C99 [0]'s section 6.7.8.19, which says: + + all subobjects that are not initialized explicitly shall be + initialized implicitly the same as objects that have static + storage duration. + +the latter clause references 6.7.8.10, which says: + + If an object that has static storage duration is not + initialized explicitly, then: + =E2=80=94 if it has pointer type, it is initialized to a null pointe= +r; + =E2=80=94 if it has arithmetic type, it is initialized to (positive = +or + unsigned) zero; + =E2=80=94 if it is an aggregate, every member is initialized + (recursively) according to these rules; + +So it's not just "an assumption", it's a guarantee from the underlying +language standard. + +That said, it's a guarantee i was unaware of until i researched this. +I'm certainly not a C guru, but i've internalized a fair amount of C's +rules and structure and i'd never heard of this +subobject-default-initialization-when-other-subobjects-are-initialized +rule before. If i'd seen the uninitialized members of the struct, and +that they were being used without explicit initialization, i would have +had to do a bit of digging to understand what's happening. + +The real tradeoff in this choice is whether we prefer: + + a) more compact code to facilitate quick reading by experts + + or + + b) more verbose code to facilitate comprehension by the non-expert. + +I started this discussion leaning strongly toward the (b) perspective. +But now that i know the relevant bits of the standard, i can sympathize +with the (a) perspective as well :P + +Overall, i think i'm still in the (b) camp. But i think it's more +important that we don't allow dithering over this issue to prevent the +inclusion of this patch series, which is a step in the right direction +for handling S/MIME messages as well as PGP/MIME. + + --dkg + +PS gcc's -pedantic argument provides the following warning: + + error: ISO C90 forbids specifying subobject to initialize + +So we probably want to specify -std=3Dc99 at least to ensure our choice o= +f +subobject initialization is respected. + +[0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf + + +--------------enig211B718926B718A80E8BA9D1 +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature +Content-Disposition: attachment; filename="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.12 (GNU/Linux) +Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ + +iQJ8BAEBCgBmBQJPtXLaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD +Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpQO4P/246CcM6ig/nB2mkmephJFTt +MJ/x5P2SCPwhCx8DfVyHco1e8WZgk/X3Q5+bHVClSpJZrsydt3qSsOfU/KG6S4kr +M6DrGv8UUpeBDNH+x5K0AW/27A9InmdEpGBeCizGyIRue/R8PU4+xgc8hox3z43r +oMuBa+VOmHmlv4dPCR6XvsxWWmOrHH/CawHD1GX1bLe6XSKnAxURgWmrPHQA+PIa +M4otEwmFGtVr2aMO7N6OyzwJ92RP40Z8Y+oGj+4q9eVQiiJo/LwAUgLjRWhwmLM0 +YMzNcFIE0sv9CQKyFziIN7NfIpunDvq2rxtEVuR1fFiA6fdIoV4JGyJaqvIkxkwW +jpOwcn3vhCzAbsLLWe+O/1/fvF8h5i52IgXm3u8HkXCixY6La3ah8J5ZY9fZd2PT +ETrmy2GCK8+GRLEAjHfbLXPubTE6KIx3kGqP63Uohi9cdAU9fLZOzm9Z6l0pdq1s +K1AobyTdKmdwhd8FWWArLfaqxz3l/09bQCYS/h9wOzfzmMuoT00UDsDdBNBRUHSc +8j/Ouj9C0EzpTTzMidfgcColwugJBhaeizlaSJDWibLDlrQlu6nxlxZCas9izSqo +6UDqv7m/vaCNAGwocoCmfFZkMBEQmrsuNtA1iJck270czAJURVFRHgC+sbXTxunH +rccpoLAnGEcTUmfqYqj2 +=eOSi +-----END PGP SIGNATURE----- + +--------------enig211B718926B718A80E8BA9D1-- -- 2.26.2