linux-kernel - Re: PATCH: Add --size-check=[error|warning]

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, 14 Mar 2011 13:56:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	sedat.dilek@...il.com
Cc:	Jan Beulich <JBeulich@...ell.com>, "H.J. Lu" <hjl.tools@...il.com>,
	Alan Modra <amodra@...pond.net.au>,
	binutils <binutils@...rceware.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: PATCH: Add --size-check=[error|warning]

* Sedat Dilek <sedat.dilek@...glemail.com> wrote:

> Nice to see there is an offer for a fix from binutils-side.

Agreed.

> That's why I am on linux-next to squash bugs, not to ignore "warnings"

We x86 arch maintainers definitely do not ignore warnings from the assembler. 
Assembler warnings were pretty good historically and seldom produce false positives.

> BTW "warnings", did someone tried gcc-4.6? I used a snapshot from mid February 
> (from Debian/experimental): My linux-next build-log and the amount of warnings 
> doubled or even more (unfortunately, I have thrown away that logs and binaries). 
> Are all of these warnings ignoreable? Which of them are really severe?

Most of those are -Wunused-but-set-variable warnings, right? I'm definitely not 
ignoring the ones that affect the code i maintain - so they are very much useful.

But if GCC broke the build unnecessarily, just to over-eagerly warn about something 
that worked fine before, that would be extremely counter-productive! In such a 
situation the Linux kernel project would likely be fed up enough to build its own 
sane compiler/assembler/linker combo and would aim to become entirely independent in 
terms of its build environment.

Thanks,

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