From e1b501efdc4e7ad3af62ca23a415b036a7037966 Mon Sep 17 00:00:00 2001 From: Jani Nikula Date: Fri, 18 May 2012 08:20:43 +0000 Subject: [PATCH] Re: [PATCH 4/6] cli: intialize crypto structure in show and reply --- dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 | 142 ++++++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 diff --git a/dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 b/dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 new file mode 100644 index 000000000..f9bea759e --- /dev/null +++ b/dd/827a27fa2ed75c7c476b8fae7778ca503bcf57 @@ -0,0 +1,142 @@ +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 30240431FB6 + for ; Fri, 18 May 2012 01:20:55 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 VZ+HLLaqsfWl for ; + Fri, 18 May 2012 01:20:50 -0700 (PDT) +Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com + [209.85.216.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 883CE431FAE + for ; Fri, 18 May 2012 01:20:50 -0700 (PDT) +Received: by qadb17 with SMTP id b17so7457069qad.5 + for ; Fri, 18 May 2012 01:20:48 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=google.com; s=20120113; + h=from:to:subject:in-reply-to:references:user-agent:date:message-id + :mime-version:content-type:x-gm-message-state; + bh=PLLeUELAknwX/a/cnA+c9djTrynuotHr/Xjtt40wX3Y=; + b=Km96I0W2cXXAoaS7Wf5M8MQetNX/XOoVBkQNNcHBYJJfk/AefLc49wNTgj0G4pHl+B + /Q5Vi8JPtYkJbEob7vZaJO/QJ4EEZiwUSXYIUqjk0zHnurgYG+8iqDsljgWkU8UMYdNE + w+e/2w1XQqvPJXxe40lVI2N89vMAEHwkOrRZKoagBIK64QxfAPeccInggXanS8ubXA0a + kuZe9i4W5AM8+v+P0+mZvO4ODLQsPPWviH8auEPRo84LxCpE7r7/xGbA6UCYpsuhegoa + amVEMOx1Ut/oqRCA3TVJmWU77fNxm1z7/DqrdrDDTlUYAFkr8lbdRwSL1mX9bF+VCiyv + d2hQ== +Received: by 10.224.175.69 with SMTP id w5mr21419318qaz.49.1337329248767; + Fri, 18 May 2012 01:20:48 -0700 (PDT) +Received: from localhost ([92.243.24.172]) by mx.google.com with ESMTPS id + ch15sm19706657qab.18.2012.05.18.01.20.47 + (version=SSLv3 cipher=OTHER); Fri, 18 May 2012 01:20:48 -0700 (PDT) +From: Jani Nikula +To: Daniel Kahn Gillmor , + Notmuch Mail +Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply +In-Reply-To: <4FB572DA.8040906@fifthhorseman.net> +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> +User-Agent: Notmuch/0.13+9~ga1668d0 (http://notmuchmail.org) Emacs/23.1.1 + (i686-pc-linux-gnu) +Date: Fri, 18 May 2012 08:20:43 +0000 +Message-ID: <87txzdew84.fsf@nikula.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Gm-Message-State: + ALoCoQl4+24lIVjmDA/WcYIBeK8XYhBSm48ywFydXRRG0f/enPEPZ6+xHQP1eg8UoINn4eaMtilA +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +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 08:20:55 -0000 + + +*sigh* I'm failing to detach myself from this conversation. :( + +On Thu, 17 May 2012, Daniel Kahn Gillmor wrote: +> 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: + +Thanks for digging up the references. + +> 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. + +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 check +the initializations. (This is why we have e.g. { 0, 0, 0, 0, 0 } instead +of just { 0 } in the initialization of notmuch_opt_desc_t arrays.) + +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 added +benefit of documenting the fields that are initialized, without having +to look at the struct definition. + +Do we now want to initialize all struct fields explicitly, everywhere, +even when using designated initializers? Isn't that the question then? +Won't that maintain and promote the misconception that explicit +initialization is required, when it's really not, failing to educate the +non-experts and planting a seed of doubt in the experts...? + +> 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 + +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. + +> 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. + +Agreed. + +> PS gcc's -pedantic argument provides the following warning: +> +> error: ISO C90 forbids specifying subobject to initialize +> +> So we probably want to specify -std=c99 at least to ensure our choice of +> subobject initialization is respected. + +Unfortunately, the notmuch code base uses mixed standards, due to GCC +being so lax about it. Anything -pedantic produces warnings: +id:"cover.1325977940.git.jani@nikula.org". You may also want to try +clang to get better warnings. + + +BR, +Jani. -- 2.26.2