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

[Tim Bell]

Magnus:

Looks good to me as well.

Tim

On 03/04/15 05:31, Erik Joelsson wrote:
> Hello,
>
> Really nice to finally see this patch getting done!
>
> Only one comment:
>
> flags.m4:
> 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?
>
> /Erik
>
> 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
>>
>