build warnings

[Dave Pointon]

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 <kellyohair at gmail.com> wrote:

>
> On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at 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
>
>
>