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:	Thu, 25 Sep 2014 00:17:33 +0000
From:	"Rustad, Mark D" <mark.d.rustad@...el.com>
To:	Borislav Petkov <bp@...en8.de>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"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 23, 2014, at 11:44 AM, Borislav Petkov <bp@...en8.de> wrote:

> Again, we should take compiler warnings with a grain of salt and judge
> them only by the quality of the generated code. IMO.

The more I thought about this, the more I think it argues for having some
diagnostic control macros. Tools such as the compiler can be very thorough -
that is their strength. The warnings that the compiler emits are things
that humans should consider. There are times when the human can judge
that nothing need be done about it, so why not use the macros to indicate
that that judgement has been made and get it out of the way so more
potentially interesting issues can be found? How many people need to
make that judgement over and over? That is clearly a waste of time and
is why these higher warning levels simply don't get looked at. So lets
capture that judgement in the code. That judgement would continue to be
open to reevaluation in any case.

The syscall issue is not arising from an include file, but I think
demonstrates the use nicely and I think is a fine example of a legitimate
use in a C file.

For me, it is about getting more value out of the evaluation that the compiler
can do. When the output of W=2 is unusable because it is so voluminous - filled
with things known to not cause problems - why not silence some of major
sources so that more interesting issues might be seen? By not doing so, W=2
has close to 0 value because no one looks at it.

I guess I also trust the maintainers to not accept lots of patches that add
uses of such macros. They have certainly demonstrated that up to this point.

:-)

-- 
Mark Rustad, Networking Division, Intel Corporation

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ