linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Cc: Joe Perches <joe@perches.com>,
	Michael Straube <straube.linux@gmail.com>,
	Larry.Finger@lwfinger.net, phil@philpotter.co.uk,
	martin@kaiser.cx, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: r8188eu: refactor rtw_is_cckrates{only}_included()
Date: Wed, 18 Aug 2021 08:33:45 +0200	[thread overview]
Message-ID: <YRypyev4Ku3eI9w8@kroah.com> (raw)
In-Reply-To: <2509261.CYLKgzzBkz@localhost.localdomain>

On Wed, Aug 18, 2021 at 08:23:18AM +0200, Fabio M. De Francesco wrote:
> Said that, since operator precedence is one of the first topic that every developer
> learn in a course on C and that expressions like *ptr++ are used everywhere in
> the kernel you are sending a dangerous message...

Operator precedence is something that no one should have to memorize or
remember.  Expressions like *ptr++ on it's own is fine, but combine it
with an assignment and then you need to think about stuff like "did it
increment before or after assigning" and the like.

And really, why?  You are doing nothing to make the code easier to
maintain by doing this.  The compiler isn't going to magically make
better code because of this.  Be explicit and obvious about what you
want the code to do, because in 10+ years when you have to look at it
again to find where to fix a problem, you want it to be really obvious
what is happening.

> It looks like you don't trust people here to be able to do anything more than 
> trivial clean-ups. If someone here at linux-staging is not able to understand 
> the precedence of operators, please stand up and speak!

I want kernel code to be simple and obvious and easy to maintain.

And yes, I do NOT remember the precedence of all C operators, and no one
should be forced to either.  And I am someone who has read or written C
code for almost every day for the past 30 years.

So keep the code simple and obvious for everyone to read and understand.
The original use of the array and then moving to the next one was just
that, simple and obvious.

Do not do unneeded optimizations just because you can, it will always
come back to hurt you, or someone else, in the end.

thanks,

greg k-h

      reply	other threads:[~2021-08-18  6:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 19:31 [PATCH] staging: r8188eu: refactor rtw_is_cckrates{only}_included() Michael Straube
2021-08-16 20:09 ` Fabio M. De Francesco
2021-08-17 17:57 ` Greg KH
2021-08-17 18:36   ` Joe Perches
2021-08-17 18:49     ` Greg KH
2021-08-17 18:59       ` Joe Perches
2021-08-18  6:23       ` Fabio M. De Francesco
2021-08-18  6:33         ` Greg KH [this message]

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=YRypyev4Ku3eI9w8@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Larry.Finger@lwfinger.net \
    --cc=fmdefrancesco@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=martin@kaiser.cx \
    --cc=phil@philpotter.co.uk \
    --cc=straube.linux@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).