linux-kernel - Re: [PATCH 0/7] Silence even more W=2 warnings

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: <4C887554-FB5F-4634-ABE6-20F41583ABA2@intel.com>
Date:	Fri, 26 Sep 2014 19:37:19 +0000
From:	"Rustad, Mark D" <mark.d.rustad@...el.com>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	Borislav Petkov <bp@...en8.de>,
	"sparse@...isli.org" <sparse@...isli.org>,
	"linux-sparse@...r.kernel.org" <linux-sparse@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] Silence even more W=2 warnings

On Sep 25, 2014, at 12:45 AM, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Instead of grepping, you can feed the build log to linux-log-summary.
> Or when changing a driver, feed the before and after build logs to
> linux-log-diff. That way you won't miss the single new warning you've
> just introduced.
> 
> https://github.com/geertu/linux-scripts

Thanks for making me aware of these tools. linux-log-summary does reduce the totally insane 125,000 warnings to the merely unreasonable 10,000 or so. I'm not being sarcastic, they *are* very nice tools that I will use. Thank you for pointing me to them.

I still observe that thousands of those unique warnings are emitted by the syscall table and its override initializations. I still think they should be silenced because they serve no purpose in that particular case. That is, the warning is complaining about what it is designed to complain about, but in this particular instance, the code is written as it needs to be, so why not acknowledge and capture that exception in the source?

A couple thousand more come from every use of compiletime_assert, for which I do not have a solution yet. Even my macros don't help with that one.

Most of the others come from null-entry table initializations, i.e. { 0 }, which give missing field initializer warnings. I'd like to define a macro something like:

#define ZERO_ENTRY DIAG_PUSH DIAG_IGNORE(missing-field-initializers) \
	{ 0 } DIAG_POP

Then simply using ZERO_ENTRY, a zero entry could be provided without a complaint from the compiler. But of course that can't be done if the DIAG_* macros aren't there. It also would keep the DIAG_* macros out of the .c files and just in the header where ZERO_ENTRY is defined.

-- 
Mark Rustad, Networking Division, Intel Corporation

Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)