linux-kernel - Re: [PATCH] staging: media: davinci_vpfe: Remove variable vpfe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190530212519.GB18779@kroah.com>
Date:   Thu, 30 May 2019 14:25:19 -0700
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Nishka Dasgupta <nishkadg.linux@...il.com>
Cc:     devel@...verdev.osuosl.org, code@...ofe.uk,
        linux-kernel@...r.kernel.org, hans.verkuil@...co.com,
        mchehab@...nel.org, ezequiel@...labora.com,
        linux-media@...r.kernel.org
Subject: Re: [PATCH] staging: media: davinci_vpfe: Remove variable vpfe_dev

On Fri, May 31, 2019 at 02:39:23AM +0530, Nishka Dasgupta wrote:
> On 31/05/19 2:25 AM, Greg KH wrote:
> > On Fri, May 31, 2019 at 02:17:18AM +0530, Nishka Dasgupta wrote:
> > > Remove variable vpfe_dev and replace it with its value (since the
> > > function otherwise uses values directly instead of local variables).
> > 
> > This says _what_ you do.  But we can see that in the patch itself.
> > 
> > You need to say _why_ you are doing this.
> > 
> > There's no need for this change at all.  Again, as I have said before,
> > we write code for developers to read first, the compiler second.  By
> > making these types of changes you are making it harder to
> > read/understand by a developer, and providing absolutely no benifit to
> > the compiler at all.
> > 
> > So it's actually making the code worse!
> > 
> > not good at all.
> > 
> > Please reconsider this type of change, as I keep asking you to.
> 
> Okay. In this case I thought it wouldn't make it worse since the function is
> low on local variables anyway? Clearly I was wrong, so I won't count this
> case as an exception in future.

Did you check the object file output to verify this?  Try it and see :)