Message-ID: <4FB68262.5010408@fifthhorseman.net>
Date: Fri, 18 May 2012 13:09:54 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 <notmuch@notmuchmail.org>
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>
	<CAB+hUn9DdeaFj-hUNb_c1V3QLsbWjsE7_hpuOpDqWseayASdKQ@mail.gmail.com>
	<87aa16daeq.fsf@servo.finestructure.net>
	<4FB572DA.8040906@fifthhorseman.net> <87txzdew84.fsf@nikula.org>
In-Reply-To: <87txzdew84.fsf@nikula.org>
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="------------enigCD3B1D6B7D91068EB0EB744D"
Precedence: list
Reply-To: notmuch <notmuch@notmuchmail.org>

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--