Amen to that Magnus - what possible motive can there be to fix invisible, benign 'problems' ?
-- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 17:42, Kelly O'Hair <kellyoh...@gmail.com> wrote: > > On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com> wrote: > > > On 2014-12-02 22:59, Jonathan Gibbons wrote: > >> Build folk, > >> > >> The build has always generated warnings (sigh!) but right now, the > warnings look scarier than usual. > >> > >> In particular, when the build terminates, I get a couple of screenfuls > of messages like this: > >> > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ‘SplashScreenThread’: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: > warning: ignoring return value of ‘pipe’, declared with attribute > warn_unused_result [-Wunused-result] > >> pipe(splash->controlpipe); > >> ^ > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: > In function ‘initFormat’: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: > warning: ‘numBits’ may be used uninitialized in this function > [-Wmaybe-uninitialized] > >> format->shift[i] = shift + numBits - i * 8 - 8; > >> ^ > >> > >> What would it take to have some sort of campaign to reduce build > warnings like these? We've made good progress on lint and doclint warnings > for Java code and doc comments; what does it take to start on native code > warnings? > > > > Actually, I've already started on such a campain. ;-) > > > > I believe the way to go is: > > 1) disable all (or more or less all) of the current flood of warnings > > 2) open bugs for all disabled warnings on the corresponding components, > indicating that the owner of the component should: > > a) fix the issue with the source code and re-enable the warning, or > > b) come up with a good reason why the warning is bad/broken and should > be left disabled for that component. > > > > I have started on 1). I have a local forest which disables most of the > warnings for linux builds. I'm about to move on to the other platforms as > well, but other work came between. > > > > /Magnus > > Speaking from a bit of experience, if you disable the warnings, odds are > good that they will never get fixed because being disabled will be > considered by some as "we have no warnings" and they will work on other > things, like adding more code with more invisible disabled warnings. > Granted some of the C/C++ compiler warnings are very dubious and of little > value, but many are not. Disabling the less valuable warnings makes sense, > but I would caution on disabling all warnings. Just my 2 cents... > > -kto > > >
