From: Dan Carpenter <dan.carpenter@oracle.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>
Cc: Ursula Braun <ursula.braun@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Frank Blaschka <blaschka@linux.vnet.ibm.com>,
linux390@de.ibm.com, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
trivial@kernel.org, Coccinelle <cocci@systeme.lip6.fr>
Subject: Re: s390/net: Deletion of unnecessary checks before two function calls
Date: Mon, 3 Nov 2014 20:16:25 +0300 [thread overview]
Message-ID: <20141103171625.GU6890@mwanda> (raw)
In-Reply-To: <5457B268.3020202@users.sourceforge.net>
On Mon, Nov 03, 2014 at 05:50:48PM +0100, SF Markus Elfring wrote:
> > After your patch then it will print warning messages.
>
> To which messages do you refer to?
>
Open your eyeballs up and read the code.
>
> > The truth is I think that all these patches are bad and they make the
> > code harder to read.
> >
> > Before: The code is clear and there is no NULL dereference.
>
> Where do you stumble on a null pointer access?
>
I'm not talking about bugs, I'm talking about code clarity. Before is
more clear than after.
>
> > After: You have to remember that rtw_free_netdev() accepts NULL
> > pointers but free_netdev() does not accept NULL pointers.
>
> Are any improvements needed for the corresponding documentation to make it
> better accessible besides the source code?
>
Documentation doesn't reduce the number of things to remember it just
documents it. Meanwhile if we leave the code as-is there is no need for
documentation because the code is clear.
>
> > The if statements are there for *human* readers to understand and you are
> > making it harder for humans to understand the code.
>
> Is there a target conflict between source code understandability
> and software efficiency?
If you can benchmark the code and the new code is faster then, yes, this
patch is good and we will apply it. If you have no benchmarks then do
not send the patch.
>
> > Even for kfree(), just removing the if statement is not really the right
> > fix. We do it because everyone knows kfree(), but what Julia Lawall
> > said is the real correct way change the code and make it simpler for
> > people to understand:
> >
> > https://lkml.org/lkml/2014/10/31/452
>
> You refer to another update suggestion for the software area
> "staging: rtl8188eu".
> Do you find adjustments for jump labels easier to accept than the simple
> deletion of specific null pointer checks?
Yes.
>
>
> > I know it's fun to send automated patches but these make the code worse
> > and they waste reviewer time.
>
> I hope that small automated changes can also help to improve affected
> source files.
No. The changes make the code less clear.
regards,
dan carpenter
next prev parent reply other threads:[~2014-11-03 17:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5307CAA2.8060406@users.sourceforge.net>
[not found] ` <alpine.DEB.2.02.1402212321410.2043@localhost6.localdomain6>
[not found] ` <530A086E.8010901@users.sourceforge.net>
[not found] ` <alpine.DEB.2.02.1402231635510.1985@localhost6.localdomain6>
[not found] ` <530A72AA.3000601@users.sourceforge.net>
[not found] ` <alpine.DEB.2.02.1402240658210.2090@localhost6.localdomain6>
[not found] ` <530B5FB6.6010207@users.sourceforge.net>
[not found] ` <alpine.DEB.2.10.1402241710370.2074@hadrien>
[not found] ` <530C5E18.1020800@users.sourceforge.net>
[not found] ` <alpine.DEB.2.10.1402251014170.2080@hadrien>
[not found] ` <530CD2C4.4050903@users.sourceforge.net>
[not found] ` <alpine.DEB.2.10.1402251840450.7035@hadrien>
[not found] ` <530CF8FF.8080600@users.sourceforge.net>
[not found] ` <alpine.DEB.2.02.1402252117150.2047@localhost6.localdomain6>
[not found] ` <530DD06F.4090703@users.sourceforge.net>
[not found] ` <alpine.DEB.2.02.1402262129250.2221@localhost6.localdomain6>
[not found] ` <5317A59D.4@users.sourceforge.net>
2014-10-31 17:40 ` [PATCH 1/1] s390/net: Deletion of unnecessary checks before two function calls SF Markus Elfring
2014-11-03 9:50 ` Dan Carpenter
2014-11-03 15:55 ` SF Markus Elfring
2014-11-03 16:25 ` Dan Carpenter
2014-11-03 16:50 ` SF Markus Elfring
2014-11-03 17:02 ` Julia Lawall
2014-11-03 17:16 ` Dan Carpenter [this message]
2014-11-03 17:40 ` SF Markus Elfring
2015-01-19 18:55 ` [PATCH 1/1] " Brian Norris
2014-11-03 11:04 ` Ursula Braun
2014-11-03 16:10 ` SF Markus Elfring
2014-11-03 16:28 ` Dan Carpenter
[not found] ` <54687F1A.1010809@users.sourceforge.net>
[not found] ` <20141116111023.GA4905@mwanda>
[not found] ` <20141116111446.GA4956@mwanda>
[not found] ` <54688F15.9070703@users.sourceforge.net>
[not found] ` <20141117073408.GC4905@mwanda>
[not found] ` <5469B836.8030507@users.sourceforge.net>
[not found] ` <20141117134515.GE4905@mwanda>
2014-11-17 14:30 ` SF Markus Elfring
2014-11-22 14:05 ` [PATCH 1/1] s390/pci: Deletion of unnecessary checks before the function call "debug_unregister" SF Markus Elfring
2014-11-24 19:06 ` Sebastian Ott
2015-06-24 20:48 ` [PATCH] s390/process: Delete an unnecessary check before the function call "kfree" SF Markus Elfring
2015-06-25 10:02 ` walter harms
2015-06-25 11:37 ` Heiko Carstens
2015-11-16 13:23 ` [PATCH] SCSI-zfcp: Delete unnecessary checks before the function call "mempool_destroy" SF Markus Elfring
2015-12-04 17:57 ` Benjamin Block
2016-01-14 14:56 ` Steffen Maier
2015-11-16 14:15 ` [PATCH] s390: Delete unnecessary checks before the function call "debug_unregister" SF Markus Elfring
2015-11-16 15:30 ` Heiko Carstens
2015-11-17 19:20 ` [PATCH] s390-ctcm: Delete unnecessary checks before the function call "channel_remove" SF Markus Elfring
2015-11-25 9:37 ` Ursula Braun
2016-07-16 18:40 ` [PATCH] s390/pci: Delete an unnecessary check before the function call "pci_dev_put" SF Markus Elfring
2016-07-18 7:00 ` Martin Schwidefsky
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=20141103171625.GU6890@mwanda \
--to=dan.carpenter@oracle.com \
--cc=blaschka@linux.vnet.ibm.com \
--cc=cocci@systeme.lip6.fr \
--cc=elfring@users.sourceforge.net \
--cc=heiko.carstens@de.ibm.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=schwidefsky@de.ibm.com \
--cc=trivial@kernel.org \
--cc=ursula.braun@de.ibm.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).