RFR: JDK-8074096 Disable (most) native warnings in JDK on a per-library basis

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Mar 4 15:03:20 UTC 2015

On 2015-03-04 14:48, Alan Bateman wrote:
> On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
>> :
>> I intend to file individual bugs to handle these remaining warnings, 
>> so the net result will be a completely warning free build.
>> I also intend to file individual bugs on all the libraries that has 
>> had warnings disabled. I expect the outcome of these bugs to be either:
>> A) The code modified so it does not trigger warnings, and the 
>> warnings re-enabled, or
>> B) The warnings (or a subset of them) kept disabled, but a comment 
>> added to the makefile describing why this is the proper course of 
>> action.
>> Not all bugs might be worth fixing. For instance, the GCC warnings 
>> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
>> deprecated-declarations, clobbered, int-to-pointer-cast and 
>> type-limits are all more or less benign, and is possibly the result 
>> of a false positive.
> Right, although for some of these it is important to double check.
I believe all warnings are important to check! Unfortunately, this has 
not been done for a lot of warnings for a lot of time. :(

With this framework, it is simple to enable a single warning, recompile 
and see the effect. Hopefully this lowers the threshold far enough so 
that all warnings are given proper attention. The incremental build 
functionality will come in very handy. Just by simply removing a warning 
from the DISABLED_WARNINGS_<toolchain> on a library and running "make" 
again, only the files affected will be recompiled.
> Do you plan to paste in the warnings into the bugs that you will 
> create? That wold be useful as warnings are a moving target.

I can easily paste in what warning categories are disabled for a 
specific library, yes.

However, if you are asking me to build each library, individually, with 
warnings re-enabled, and pasting the output, I'd rather not. That would 
be a lot of work, to detangle the output of each individual library.


More information about the security-dev mailing list