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

<p>BR,<br>
Jani.<br></p>
<p>><br>
> jamie.<br>
</p>