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] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070429163701.fb994561.randy.dunlap@oracle.com>
Date:	Sun, 29 Apr 2007 16:37:01 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Matt Mackall <mpm@...enic.com>
Cc:	Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: checkpatch, a patch checking script.

On Sat, 28 Apr 2007 12:21:54 -0500 Matt Mackall wrote:

> On Sat, Apr 28, 2007 at 01:11:01PM -0400, Dave Jones wrote:
> > On Sat, Apr 28, 2007 at 11:11:36AM -0500, Matt Mackall wrote:
> >  > > I'm all ears for additional regexps, bug reports or other suggestions.
> >  > 
> >  > Neat.
> >  > 
> >  > Does it check for:
> >  > 
> >  > functions marked extern?

	data marked extern?

> >  > pulling in external functions or variables without a header file?
> >  > return used as a function, eg return(foo);?
> > 
> > These sound a little more tricky than just dumb regexps.
> > I don't want to expand this to a fullblown C parser (given
> > that we have sparse which can do a better job), but I don't
> > object to adding some extra code to give the searches more
> > context.
> 
> The first is a straightforward one-line regexp, as is the last:
> 
> ^extern \w.*\w\(

Just omit the ending \( to catch functions or data.
Added.

> return\s?\(

Added.  Thanks.

> The middle one is a bit trickier. Basically, we don't want people
> doing either:
> 
> extern int capital_of_assyria;
> int sir_not_appearing_in_this_module();
> 
> in .c files. The first of those two is easy, provided you can figure
> out the file type. And both are possible with multiline regexps.
> 
> This whole thing would be quite a bit more powerful if your search
> function joined all the lines together, did a potentially multiline
> search, then calculated the line numbers from the search results. Then
> you could search for things like:
> 
> if (...)
> {
> 
> if (...) {
>   single_statement;
> }
> 
> Looking forward to fully-automated pedantry. This should probably live
> in scripts/.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ