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