From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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--