linux-kernel - Re: [PATCH] checkpatch: ignore ethtool CamelCase constants

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 22 Oct 2020 11:29:50 -0700
From:   Joe Perches <joe@...ches.com>
To:     Lukasz Stelmach <l.stelmach@...sung.com>
Cc:     Andy Whitcroft <apw@...onical.com>, linux-kernel@...r.kernel.org,
        Bartłomiej Żolnierkiewicz 
        <b.zolnierkie@...sung.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH] checkpatch: ignore ethtool CamelCase constants

On Thu, 2020-10-22 at 20:14 +0200, Lukasz Stelmach wrote:
> It was <2020-10-22 czw 04:57>, when Joe Perches wrote:
> > On Thu, 2020-10-22 at 13:01 +0200, Łukasz Stelmach wrote:
> > > Ignore CamelCase constants describing Ethernet link parameters defined
> > > in include/uapi/linux/ethtool.h.
> > []
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > []
> > > @@ -5295,6 +5295,10 @@ sub process {
> > >  #CamelCase
> > >  			if ($var !~ /^$Constant$/ &&
> > >  			    $var =~ /[A-Z][a-z]|[a-z][A-Z]/ &&
> > > +#Ignore constants from include/uapi/linux/ethtool.h
> > > +			    $var !~ /^ETHTOOL_LINK_MODE_[0-9A-Za-z_]+_BIT$/ &&
> > > +			    $var !~ /^ADVERTISED_[0-9A-Za-z_]+$/ &&
> > > +			    $var !~ /^SUPPORTED_[0-9A-Za-z_]+$/ &&
> > >  #Ignore Page<foo> variants
> > >  			    $var !~ /^(?:Clear|Set|TestClear|TestSet|)Page[A-Z]/ &&
> > >  #Ignore SI style variants like nS, mV and dB
> > 
> > How about changing this to be a bit broader?
> > 
> > $var !~ /^(?:[A-Z]+_){1,5}[A-Z]{1,3}[a-z]/
[]
> And we've got enums too.

The regex finds the enums too.
The added 'define' was just to show a simple list.
[]
> Oh, I had no idea there is so many of them. Your regex loooks
> reasonable. However, I am afraid it may allow for some false negatives
> (stuff that should be fixed, but won't be reported). I don't know.

Me neither, but I think it's simpler than the specific
exclusions and I'm generally in favor of simpler.

Most all of the matches it excludes are autogenerated
and would never have been fixed so I think we should
use the regex.