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: <1352381151.9901.5.camel@joe-AO722>
Date:	Thu, 08 Nov 2012 05:25:51 -0800
From:	Joe Perches <joe@...ches.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Andy Whitcroft <apw@...onical.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] checkpatch: Add a --strict test for macro argument
 reuse

On Tue, 2012-11-06 at 12:00 -0800, Andrew Morton wrote:
> On Tue, 06 Nov 2012 02:35:39 -0800
> Joe Perches <joe@...ches.com> wrote:
> 
> > Add a test for reuse of macro arguments to highlight
> > any possible side-effects from this reuse.
> > 
> > Avoid this check on token name pasting and when the
> > argument is used in a typeof or a __builtin.
> 
> Does this mean that if I do
> 
> 	#define foo(a) bar(a, a)
> 
> that checkpatch will not generate a warning unless I give it
> "--strict"?  If so: whaaah!  I want that warning to come out by
> default.

Well, that was the intent, yes.

I wanted to avoid a bunch of people "improving" simple macros
with a normal checkpatch run on files like include/linux/kernel.h

> Not being totally lazy, I tried it myself but my perl v5.10.1 had
> conniptions over this patch:

Because I had originally used ERROR but decided to use the
incorrect form of CHECK instead of CHK when I submitted the
patch.  Sorry.

Anyway, do try it on include/linux files with -f and see if
you think it's really appropriate to have the thing report
this type of error.

Dunno.  Maybe it's appropriate to warn on .diff/.patch files
but only emit the message  on checkpatch -f --strict uses.

I generally don't like different behavior based on runtime
input.  Shrug.  Who knows what's right here.

--
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