[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YRypyev4Ku3eI9w8@kroah.com>
Date: Wed, 18 Aug 2021 08:33:45 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: "Fabio M. De Francesco" <fmdefrancesco@...il.com>
Cc: Joe Perches <joe@...ches.com>,
Michael Straube <straube.linux@...il.com>,
Larry.Finger@...inger.net, phil@...lpotter.co.uk, martin@...ser.cx,
linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: r8188eu: refactor
rtw_is_cckrates{only}_included()
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
Powered by blists - more mailing lists