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 A1C97431FC2 for ; Thu, 17 May 2012 09:32:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 Pu6-Fo+6Z6Wd for ; Thu, 17 May 2012 09:32:01 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id E639D431FAE for ; Thu, 17 May 2012 09:32:00 -0700 (PDT) Received: by obbuo19 with SMTP id uo19so3102612obb.26 for ; Thu, 17 May 2012 09:31:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fHo9KovhABXYVu3XD+A+GFUrZqRNqUHvOJIxDU+fhNQ=; b=O/rTGoCXh1FcZL6nlAIvQ8oqIIcb2nT1z4v2uw0o4X0LKUQ/2ptyQfG2GJXJmtw/s0 jXsZskBPXvgr+jVvVo4DS4RM3bb2d+U/Eg14Tuud4589insFeL1yHrwjCVJCA34bSthL kFfRPjAsnzNqGVK4ZtEqHlPhMPl1idDYpqwqabjP17x4REikXfvTNEIegmPo9Z7EZ15b EBpcfo2OGhE/R/L0Jl9BrrVqi8hJEAYhZqDFdmHSyt7kKyg8X4IyqiWRhjGAd90M6/wa LlZpaVnUBzMLfcEks2yo0VjuarjR9/pPf/hsN38bZa8Wvx6gUw9yFLv6Q2bTiU5F632f rOIQ== MIME-Version: 1.0 Received: by 10.182.167.68 with SMTP id zm4mr7178368obb.25.1337272319458; Thu, 17 May 2012 09:31:59 -0700 (PDT) Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT) Received: by 10.76.7.101 with HTTP; Thu, 17 May 2012 09:31:59 -0700 (PDT) In-Reply-To: <877gwaeve1.fsf@servo.finestructure.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> Date: Thu, 17 May 2012 19:31:59 +0300 Message-ID: Subject: Re: [PATCH 4/6] cli: intialize crypto structure in show and reply From: Jani Nikula To: Jameson Graef Rollins Content-Type: multipart/alternative; boundary=e89a8f83a5a191be2804c03df912 X-Gm-Message-State: ALoCoQl2ZMcZRuDRBwGDM3va+hXYNjRJ0VQTIL5pVapQewHol8Hp1xySxCHpQjNfzEXGGTGexJyA Cc: Notmuch Mail 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: Thu, 17 May 2012 16:32:01 -0000 --e89a8f83a5a191be2804c03df912 Content-Type: text/plain; charset=UTF-8 On May 17, 2012 5:26 PM, "Jameson Graef Rollins" wrote: > > On Thu, May 17 2012, Jani Nikula wrote: > > On Thu, 17 May 2012, Jameson Graef Rollins wrote: > >> This makes sure it has proper initialization values when it's created. > > > > Please don't do this. It's unnecessary; if one field is initialized with > > a designated initializer, the rest are initialized to zero (or NULL). > > It may be technically unnecessary, but why is that a reason to not do > it? I intentionally did this to make it clear what the defaults are. > Otherwise the defaults are essentially undefined, which is not good. > Maybe the structure initializes to the correct defaults, but why count > on that when we can set them to the correct default, and have it clear > to readers of the code? The values are not undefined, they are properly initialized, and we can count on it. For sure, not maybe. If you want to explicitly set them for clarity, it's a matter of taste. Personally I find it too verbose, but then again notmuch code is generally fairly verbose. If you insist on it, please at least drop the extra temp crypto variable, and initialize the struct in one initializer. BR, Jani. > > jamie. --e89a8f83a5a191be2804c03df912 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On May 17, 2012 5:26 PM, "Jameson Graef Rollins" <jrollins@finestructure.net> wrote:=
>
> On Thu, May 17 2012, Jani Nikula <jani@nikula.org> wrote:
> > On Thu, 17 May 2012, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> >> This makes sure it has proper initialization values when it&#= 39;s created.
> >
> > Please don't do this. It's unnecessary; if one field is i= nitialized with
> > a designated initializer, the rest are initialized to zero (or NU= LL).
>
> It may be technically unnecessary, but why is that a reason to not do<= br> > it? =C2=A0I intentionally did this to make it clear what the defaults = are.
> Otherwise the defaults are essentially undefined, which is not good. > Maybe the structure initializes to the correct defaults, but why count=
> on that when we can set them to the correct default, and have it clear=
> to readers of the code?

The values are not undefined, they are properly initialized, and we can = count on it. For sure, not maybe. If you want to explicitly set them for cl= arity, it's a matter of taste. Personally I find it too verbose, but th= en again notmuch code is generally fairly verbose. If you insist on it, ple= ase at least drop the extra temp crypto variable, and initialize the struct= in one initializer.

BR,
Jani.

>
> jamie.

--e89a8f83a5a191be2804c03df912--