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

Erik Joelsson erik.joelsson at oracle.com
Wed Mar 4 13:31:53 UTC 2015


Really nice to finally see this patch getting done!

Only one comment:

In the grep expression, could you move the extra [] outside of the 
actual command line options to grep so that the command line could be 
copied to the shell for debugging in the future? Also, how hard would it 
be to instead do AC_COMPILE_IFELSE with a dummy warning to instead test 
for capability?


On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
> When building the native code in the jdk repo, a lot of warnings are 
> generated. So many that it's hard to spot any new issues.
> While the ultimate goal must be to address and fix these warnings 
> individually, this bug is about disabling these warnings where they 
> occur, so that it is easier to spot new warnings, and that the 
> existing warnings can be addressed one at a time.
> Disabling warnings instead of fixing them can be problematic. If you 
> are too broad with disabling warnings, you might hide future problems. 
> On the other hand, there have been a lot of warnings that indicate 
> serious problems that has been "hidden in plain sight" for a very long 
> time in the code base anyway.
> I have opted to disable warnings at the library level. Disabling 
> warnings globally would be too broad. Disabling per file would have 
> been too tedious. Many warnings also tend to repeat across multiple 
> files in the same library, due to e.g. less well-suited programming 
> style or design choice. A library also seems like a suitable chunk of 
> work to address later on, in trying to get rid of the source of the 
> warnings.
> This fix will not get rid of all warnings, but the bulk of them. It 
> will make the remaining warnings stick out more. The few warnings that 
> remain are either:
> * Not possible to disable.
> * Not resulting from native compilation (but from linking, or javadoc, 
> etc).
> * Not possible to disable with this framework (this goes for builds on 
> pre-4.4 gcc, which Oracle currently does as default on macosx), and 
> libfontmanager on Solaris, which mixes C and C++ code. (While the 
> solstudio C compiler does not fail on requests to disable C++ 
> warnings, the converse is unfortunately not true). It did not seem 
> worth the trouble to build a more extensible framework to handle this, 
> compared to actually fixing these warnings.
> Note that the current JPRT build environment in Oracle uses a pre-4.4 
> gcc for macosx by default, so the default macosx build will still 
> contain warnings. When building with --with-toolchain-type=clang, the 
> clang warning disabling kicks in. (This will be the default in JPRT 
> later on this year.)
> 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.
> On the other hands, warnings such as format-nonliteral, unused-result, 
> maybe-uninitialized, format, format-security, int-to-pointer-cast, 
> reorder and delete-non-virtual-dtor are more likely to actually point 
> to real issues. I recommend anyone finding these warnings on a library 
> they care about to try and fix them as soon as possible.
> Here is a summary of the libraries and binaries that have gotten 
> warnings disabled. I'm not sure about what group owns all these 
> libraries; if I missed sending this mail to the correct list, please 
> help me and forward it.
> * libunpack
> * libfdlibm
> * libverify
> * libjava
> * libzip
> * libjli/libjli_static
> * libj2gss
> * libsunec
> * libj2pkcs11
> * libnet
> * libnio
> * libosxkrb5
> * libosxapp
> * libosx
> * libapplescriptengine
> * libjsound
> * libjsoundalsa
> * libmlib_image
> * libawt
> * libawt_xawt
> * libawt_lwawt
> * liblcms
> * libjavajpeg
> * libawt_headless
> * libfontmanager
> * libsplashscreen
> * unpack200
> * The JVMTI demos compiledMethodLoad and waiters
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
> /Magnus

More information about the security-dev mailing list