[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ACACCEEA-32F7-4296-B562-C83299BDFAD5@intel.com>
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