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:	Fri, 08 Jan 2016 12:31:54 +1100
From:	Ian Munsie <imunsie@....ibm.com>
To:	Brian Norris <computersforpeace@...il.com>
Cc:	Daniel Axtens <dja@...ens.net>, Arnd Bergmann <arnd@...db.de>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Michael Neuling <mikey@...ling.org>,
	Anton Blanchard <anton@....ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Michal Marek <mmarek@...e.com>
Subject: Re: Build failure: -Wno-unused-const-variable DNE on old GCC

Excerpts from Brian Norris's message of 2016-01-08 10:02:25 +1100:
> >  - It forces cxl developers to a higher standard. cxl has already had
> >    more than it's fair share of incredibly difficult to debug issues,
> >    so any way we can reduce the risk of errors going in makes our lives
> >    (and our end-users lives) better.
> 
> One problem with this point: not all warnings are under the purview of
> cxl developers. For instance, if I turn up warning verbosity (W=1), then
> the *header* files start producing plenty of warnings. Should this break
> the build? Your code didn't change, and you can't fix those errors.

That's a good point, but the specific warnings that we suppressed in the
new compiler are in drivers/misc/cxl/cxl.h, which is an internal header
that should only ever be included by the cxl driver. We do have some
headers elsewhere which are included by other drivers, the generic ppc
architecture code and userspace, but these are all warning free and
won't be affected by the -Werror when included from elsewhere.

> That is a real use case for me daily: I turn the warning verbosity up on
> my compile tests, then (smart)diff the build logs before and after
> new patches. That way, I can see what new warnings (even potentially
> false positive ones) are introduced. I can't do that if every random
> developer wants to stick -Werror in their Makefile.

Makes sense.

> I think there are plenty of reasons to either remove -Werror, or make it
> configurable. Some of them are detailed above.
>
> Maybe you can gate the -Werror on CONFIG_PPC_WERROR, just like the rest
> of PowerPC?

Agreed.

@Daniel - since you added the -Werror do you want to do this, or shall
I?

Cheers,
-Ian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ