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: <20211206133100.GA1956@kadam>
Date:   Mon, 6 Dec 2021 16:31:00 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Alberto Merciai <alb3rt0.m3rciai@...il.com>
Cc:     Pavel Skripkin <paskripkin@...il.com>,
        Forest Bond <forest@...ttletooquiet.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tommaso Merciai <tomm.merciai@...il.com>,
        Aldas Taraškevičius <aldas60@...il.com>,
        Karolina Drobnik <karolinadrobnik@...il.com>,
        Lucas Henneman <lucas.henneman@...aro.org>,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: vt6655: refactor byMinChannel to min_channel

On Sat, Dec 04, 2021 at 10:09:41AM +0100, Alberto Merciai wrote:
> On Sat, Dec 04, 2021 at 11:27:43AM +0300, Pavel Skripkin wrote:
> > Looks like this variable is set, but never used. Shouldn't it be just
> > removed?
> > 
> > Same for max_channel (or byMaxChannel).
> 
> To be honest, I would prefer leave them where they are. I'm only
> refactoring the code considering less the logic aspect.
> 

Pavel is right.

You should always be looking for that kind of stuff instead of just
doing a sed script.  And the thing is you're in the best place to think
about how each struct member is used right now because you're modifying
each use to make sure it compiles.  There is a possibility that no one
else will think about it ever again now that checkpatch doesn't
complain.

So in a way, it's better to leave the checkpatch warning as-is until
someone can fix it properly.

> I don't know if these variables will become usefull in a second
> moment.

No.  We do not write code for the future.  No one knows what the future
will hold.  Delete any code which is not currently useful.

regards,
dan carpenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ