[PATCH 4/6] cli: intialize crypto structure in show and reply

[Daniel Kahn Gillmor]

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.  

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:
     — if it has pointer type, it is initialized to a null pointer;
     — if it has arithmetic type, it is initialized to (positive or
       unsigned) zero;
     — 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=c99 at least to ensure our choice of
subobject initialization is respected.

[0] http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120517/59f634ea/attachment.pgp>