On Mon, 5 May 2014 22:39:09 -0500 Garg Vakul-B16394 <va...@freescale.com> wrote:
> Hi Kim Hi Vakul, > > From: Kim Phillips [mailto:kim.phill...@freescale.com] > > Sent: Tuesday, May 06, 2014 12:07 AM > > > > On Sat, 3 May 2014 06:44:39 -0500 > > Garg Vakul-B16394 <va...@freescale.com> wrote: > > > > > > From: Kim Phillips [mailto:kim.phill...@freescale.com] > > > > Sent: Saturday, May 03, 2014 5:40 AM > > > > > > > > On Sun, 27 Apr 2014 11:26:14 -0400 > > > > Vakul Garg <va...@freescale.com> wrote: > > > > > > > > > @@ -220,6 +220,8 @@ static int aead_null_set_sh_desc(struct > > > > > crypto_aead > > > > *aead) > > > > > if (DESC_AEAD_NULL_ENC_LEN + DESC_JOB_IO_LEN + > > > > > ctx->split_key_pad_len <= CAAM_DESC_BYTES_MAX) > > > > > keys_fit_inline = true; > > > > > + else > > > > > + keys_fit_inline = false; > > > > > > > > Can we do the easier to read: > > > > > > > > keys_fit_inline = false; > > > > if (DESC_AEAD_NULL_ENC_LEN + DESC_JOB_IO_LEN + > > > > ctx->split_key_pad_len <= CAAM_DESC_BYTES_MAX) > > > > keys_fit_inline = true; > > > > > > > > ? > > > > > > Why pre-init a variable with default value when it could be > > overwritten? > > > > why not? compiler output doesn't differ in this regard. > > Agree that compiler output doesn't differ. > But why depend upon compiler's optimization capability while writing code > when we can be explicit? ? with optimizations turned off, the explicit 'else' *adds* an extra CoF.. > > > I think that the form I submitted is equally easy to read. > > > > adding one line instead of two -> less lines overall -> more code on one > > screen -> easier to read. > > I think that this is a matter of personal coding choice. > Both the approaches are fine and compliant to kernel coding guidelines. I disagree, for the reasons already mentioned above. Kim -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
