linux-kernel - Re: [Proposal] end of file checks by checkpatch.pl

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: <a28b0616aca51aed38fd99fb85632628e6fd8d60.camel@perches.com>
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.