All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Megha Dey <megha.dey@intel.com>,
	"Wang, Rui Y" <rui.y.wang@intel.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Xiaodong Liu <xiaodong.liu@intel.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [patch] crypto: sha256-mb - cleanup a || vs | typo
Date: Fri, 01 Jul 2016 07:55:59 +0000	[thread overview]
Message-ID: <20160701075559.GA11902@gmail.com> (raw)
In-Reply-To: <1467319339.22178.256.camel@linux.intel.com>


* Tim Chen <tim.c.chen@linux.intel.com> wrote:

> On Wed, 2016-06-29 at 10:05 -0700, H. Peter Anvin wrote:
> > On 06/29/16 07:42, Dan Carpenter wrote:
> > > 
> > > > 
> > > > > 
> > > > > and | behave basically the same here but || is intended.  It causes a
> > > static checker warning to mix up bitwise and logical operations.
> > > 
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > 
> > > diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c b/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > index c9d5dcc..4ec895a 100644
> > > --- a/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > +++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > @@ -299,7 +299,7 @@ static struct sha256_hash_ctx *sha256_ctx_mgr_submit(struct sha256_ctx_mgr *mgr,
> > >  	 * Or if the user's buffer contains less than a whole block,
> > >  	 * append as much as possible to the extra block.
> > >  	 */
> > > -	if ((ctx->partial_block_buffer_length) | (len < SHA256_BLOCK_SIZE)) {
> > > +	if ((ctx->partial_block_buffer_length) || (len < SHA256_BLOCK_SIZE)) {
> > >  		/* Compute how many bytes to copy from user buffer into
> > >  		 * extra block
> > >  		 */
> > > 
> > As far as I know the | was an intentional optimization, so you may way
> > to look at the generated code.
> > 
> > 	-hpa
> > 
> 
> Yes, this is an intentional optimization. [...]

Please don't do intentional optimizations while mixing them with a very ugly 
coding style:

	if ((ctx->partial_block_buffer_length) | (len < SHA256_BLOCK_SIZE)) {

The extra, unnecessary parantheses around ctx->partial_block_buffer_length will 
make the ordinary reader assume that the person who wrote the code was unsure 
about basic C syntax details and typoed the '|' as well ...

Also, for heaven's (and readability's) sake, pick shorter structure field names. 
What's wrong with ctx->partial_block_buf_len?

Also, even if the '|' was intentional - wouldn't it result in better code to use 
'||'?

Plus:

> > >  		/* Compute how many bytes to copy from user buffer into
> > >  		 * extra block
> > >  		 */

please use the customary (multi-line) comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

        Ingo
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Megha Dey <megha.dey@intel.com>,
	"Wang, Rui Y" <rui.y.wang@intel.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Xiaodong Liu <xiaodong.liu@intel.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [patch] crypto: sha256-mb - cleanup a || vs | typo
Date: Fri, 1 Jul 2016 09:55:59 +0200	[thread overview]
Message-ID: <20160701075559.GA11902@gmail.com> (raw)
In-Reply-To: <1467319339.22178.256.camel@linux.intel.com>


* Tim Chen <tim.c.chen@linux.intel.com> wrote:

> On Wed, 2016-06-29 at 10:05 -0700, H. Peter Anvin wrote:
> > On 06/29/16 07:42, Dan Carpenter wrote:
> > > 
> > > > 
> > > > > 
> > > > > and | behave basically the same here but || is intended.  It causes a
> > > static checker warning to mix up bitwise and logical operations.
> > > 
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > 
> > > diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c b/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > index c9d5dcc..4ec895a 100644
> > > --- a/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > +++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
> > > @@ -299,7 +299,7 @@ static struct sha256_hash_ctx *sha256_ctx_mgr_submit(struct sha256_ctx_mgr *mgr,
> > >  	 * Or if the user's buffer contains less than a whole block,
> > >  	 * append as much as possible to the extra block.
> > >  	 */
> > > -	if ((ctx->partial_block_buffer_length) | (len < SHA256_BLOCK_SIZE)) {
> > > +	if ((ctx->partial_block_buffer_length) || (len < SHA256_BLOCK_SIZE)) {
> > >  		/* Compute how many bytes to copy from user buffer into
> > >  		 * extra block
> > >  		 */
> > > 
> > As far as I know the | was an intentional optimization, so you may way
> > to look at the generated code.
> > 
> > 	-hpa
> > 
> 
> Yes, this is an intentional optimization. [...]

Please don't do intentional optimizations while mixing them with a very ugly 
coding style:

	if ((ctx->partial_block_buffer_length) | (len < SHA256_BLOCK_SIZE)) {

The extra, unnecessary parantheses around ctx->partial_block_buffer_length will 
make the ordinary reader assume that the person who wrote the code was unsure 
about basic C syntax details and typoed the '|' as well ...

Also, for heaven's (and readability's) sake, pick shorter structure field names. 
What's wrong with ctx->partial_block_buf_len?

Also, even if the '|' was intentional - wouldn't it result in better code to use 
'||'?

Plus:

> > >  		/* Compute how many bytes to copy from user buffer into
> > >  		 * extra block
> > >  		 */

please use the customary (multi-line) comment style:

  /*
   * Comment .....
   * ...... goes here.
   */

specified in Documentation/CodingStyle.

Thanks,

        Ingo

  parent reply	other threads:[~2016-07-01  7:55 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-29 14:42 [patch] crypto: sha256-mb - cleanup a || vs | typo Dan Carpenter
2016-06-29 14:42 ` Dan Carpenter
2016-06-29 17:05 ` H. Peter Anvin
2016-06-29 17:05   ` H. Peter Anvin
2016-06-30  7:50   ` Dan Carpenter
2016-06-30  7:50     ` Dan Carpenter
2016-06-30 11:16     ` Joe Perches
2016-06-30 11:16       ` Joe Perches
2016-06-30 11:45       ` walter harms
2016-06-30 11:45         ` walter harms
2016-06-30 12:33         ` Dan Carpenter
2016-06-30 12:33           ` Dan Carpenter
2016-06-30 20:42   ` Tim Chen
2016-06-30 20:42     ` Tim Chen
2016-06-30 22:16     ` Dan Carpenter
2016-06-30 22:16       ` Dan Carpenter
2016-07-01  7:55     ` Ingo Molnar [this message]
2016-07-01  7:55       ` Ingo Molnar
2016-07-01  9:28       ` Herbert Xu
2016-07-01  9:28         ` Herbert Xu
2016-07-01 10:13         ` Ingo Molnar
2016-07-01 10:13           ` Ingo Molnar
2016-07-08 16:28           ` Tim Chen
2016-07-08 16:28             ` Tim Chen
2016-07-08 16:45             ` Herbert Xu
2016-07-08 16:45               ` Herbert Xu
2016-07-08 17:17               ` Tim Chen
2016-07-08 17:17                 ` Tim Chen
2016-07-08 17:19               ` Linus Torvalds
2016-07-08 17:19                 ` Linus Torvalds
2016-07-11  6:40                 ` Geert Uytterhoeven
2016-07-11  6:40                   ` Geert Uytterhoeven
2016-07-18  8:59                 ` Pavel Machek
2016-07-18  8:59                   ` Pavel Machek
2016-07-18 22:12                   ` Tim Chen
2016-07-18 22:12                     ` Tim Chen
2016-07-18 22:12                     ` Tim Chen
2016-07-11 10:09             ` Herbert Xu
2016-07-11 10:09               ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160701075559.GA11902@gmail.com \
    --to=mingo@kernel.org \
    --cc=dan.carpenter@oracle.com \
    --cc=davem@davemloft.net \
    --cc=dvlasenk@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=megha.dey@intel.com \
    --cc=mingo@redhat.com \
    --cc=rui.y.wang@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@kernel.org \
    --cc=xiaodong.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.