From c4b82d45f22abdee55252fbfa0ef6519bf01825e Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Sat, 19 May 2012 13:09:54 +2000 Subject: [PATCH] Re: [PATCH 4/6] cli: intialize crypto structure in show and reply --- 88/ba12197379b150c03a08ad83d2e213bf0cd010 | 144 ++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 88/ba12197379b150c03a08ad83d2e213bf0cd010 diff --git a/88/ba12197379b150c03a08ad83d2e213bf0cd010 b/88/ba12197379b150c03a08ad83d2e213bf0cd010 new file mode 100644 index 000000000..d15572ebb --- /dev/null +++ b/88/ba12197379b150c03a08ad83d2e213bf0cd010 @@ -0,0 +1,144 @@ +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 39777431FB6 + for ; Fri, 18 May 2012 10:10:06 -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 NWn-R6lopsqT for ; + Fri, 18 May 2012 10:10:05 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) + by olra.theworths.org (Postfix) with ESMTP id 83284431FAE + for ; Fri, 18 May 2012 10:10:05 -0700 (PDT) +Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net + [216.254.70.154]) + by che.mayfirst.org (Postfix) with ESMTPSA id 08889F970 + for ; Fri, 18 May 2012 13:10:03 -0400 (EDT) +Message-ID: <4FB68262.5010408@fifthhorseman.net> +Date: Fri, 18 May 2012 13:09:54 -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> + <4FB572DA.8040906@fifthhorseman.net> <87txzdew84.fsf@nikula.org> +In-Reply-To: <87txzdew84.fsf@nikula.org> +X-Enigmail-Version: 1.4.1 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; + boundary="------------enigCD3B1D6B7D91068EB0EB744D" +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: Fri, 18 May 2012 17:10:06 -0000 + +This is an OpenPGP/MIME signed message (RFC 2440 and 3156) +--------------enigCD3B1D6B7D91068EB0EB744D +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +On 05/18/2012 04:20 AM, Jani Nikula wrote: +> We have -Wextra, which enables -Wmissing-field-initializers, which +> requires us to use full initialization of struct fields when doing +> regular, non-designated initialization. The point is that you might +> introduce subtle bugs if you added new struct fields and forgot to chec= +k +> the initializations. (This is why we have e.g. { 0, 0, 0, 0, 0 } instea= +d +> of just { 0 } in the initialization of notmuch_opt_desc_t arrays.) + +i think we can agree that this is the right choice. We might even want +to discourage non-designated initializations entirely. + +> IMHO the whole point of designated initializers is that the +> initialization is not vulnerable to struct changes, and you can pick +> which fields you choose to initialize explicitly. Also, it has the adde= +d +> benefit of documenting the fields that are initialized, without having +> to look at the struct definition. + +Agreed. + +> Do we now want to initialize all struct fields explicitly, everywhere, +> even when using designated initializers? Isn't that the question then? + +I'm not sure it has to be this dramatic and "all or nothing". For +example, it could be reasonable to explicitly initialize some subobjects +and not others. For example, the notmuch_crypto_t jamie is proposing +would effectively encode the default setting for the --verify and +--decrypt flags. I could see wanting to explicitly initialize those +default policy choices, even if they happen to be identical to the +implicit "zero"ing. + +> Won't that maintain and promote the misconception that explicit +> initialization is required, when it's really not, failing to educate th= +e +> non-experts and planting a seed of doubt in the experts...? + +i see your point here, which is why i'm not arguing that all subobjects +need to be explicitly initialized all the time. + +> It's not always clear whether something is a matter of taste, style, or= + +> language paradigm. If it feels like a paradigm, sticking with it +> ultimately benefits *both* perspectives. + +yep, understood. + + --dkg + + +--------------enigCD3B1D6B7D91068EB0EB744D +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/ + +iQJ8BAEBCgBmBQJPtoJoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD +Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznprlQQAJZm0916WkpKy1xSzXu1UlEJ +4L1HSEf27PhnF09cwM0acCjsAYMFKC2ts9semIrKujU68OwVNKauAyMQ8FgDc7n0 +yNPfz4PjvifTNpDJkUlryS4wSUVtAv6RUVei0QnjmpzR3EWsXZ3Xs+XMp/MC8mt9 +VqNu7HRFBa/0u7A6WMd16Yy5PpYkT/EkaS3d+Y1LjcPhVXBN0pVYfQiRE5Xdt7KO +kFC17xhsgYC70h0PQfjCLwbj9u7yew+59R3wMU0H+cWYvFXfeX5dOjYjUluV/jSB +sEwkCmC9YHWzZELLv0BzdoXnidfUMf7yUbJoHLYTyKM//lcvuJc+Sp3WRljzxKiQ +JmPekHlbNIoMmFMobwmE7MpRjcoxB7sG2bp318FbFRO0I2py8ZbQGWfgpVaZ55JO +HnLpQ4Jn+aVeL1K9a4uWhzI2ONS1ygWbv2I1v7I01xgqNEe54rk3o9UQjYq+en/B +8xp9HnIRdMgtRKFQnS1XzEZMTN7HSReCQscbCv5dIMCXsdoqDvJulXWKrIvpaXI3 +2zFRHkV42AsWRsu4tDtP87q1G/xEHSbbU2AbOJolXrgxfowvv/d6h5kkvfAH8s7U +SifvEQn/FdEy7jZqjPNWu9t4ipYS+/XBkQsf7szQre3bbXV2JmHGFOFzIGpvGKed +xRI1B1/LlSGw/52duuWE +=uptl +-----END PGP SIGNATURE----- + +--------------enigCD3B1D6B7D91068EB0EB744D-- -- 2.26.2