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]
Date:   Mon, 13 May 2019 08:51:18 -0700
From:   Joe Perches <joe@...ches.com>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Whitcroft <apw@...onical.com>
Subject: Re: [Proposal] end of file checks by checkpatch.pl

On Mon, 2019-05-13 at 19:11 +0900, Masahiro Yamada wrote:
> Hi Joe,

Hello again.

> On Fri, May 10, 2019 at 2:20 AM Joe Perches <joe@...ches.com> wrote:
> > On Fri, 2019-05-10 at 00:27 +0900, Masahiro Yamada wrote:
> > > Does it make sense to check the following
> > > by checkpatch.pl ?
> > > [1] blank line at end of file
> > > [2] no new line at end of file
> > 
> > I'm pretty sure checkpatch does one this already.
[]
> Looks like the report depends on the file type.
> 
> scripts/checkpatch.pl  -f  arch/sparc/lib/NG4clear_page.S
> scripts/checkpatch.pl  -f  tools/power/cpupower/bench/cpufreq-bench_plot.sh
> 
> reported it, but
> 
> scripts/checkpatch.pl  -f  drivers/media/dvb-frontends/cxd2880/Kconfig
> scripts/checkpatch.pl  -f  drivers/parport/Makefile
> 
> did not.

Yes, this check is after a test for filename extension.

Currently the only file types it reports as missing an EOF
newline are done on files with the following extensions:

	.h
	.c
	.s
	.S
	.sh
	.dtsi
	.dts

So the existing test is not done on many file types.
The same file types are used for the proposed patch.

It's possible to have the existing missing newline at EOF
test and the proposed test for a blank line at EOF to be
done on all file types.

Is this reasonable or could it cause some other issue
for any other file types?  Should _any_ file extension
be excluded?

I believe not, but perhaps it's best to ask.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ