On Sep 23, 2014, at 11:44 AM, Borislav Petkov <bp@xxxxxxxxx> 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-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
