pointo1d at gmail.com
Wed Dec 3 18:13:17 UTC 2014
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 -
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:
> In function ‘SplashScreenThread’:
> warning: ignoring return value of ‘pipe’, declared with attribute
> warn_unused_result [-Wunused-result]
> >> pipe(splash->controlpipe);
> >> ^
> In function ‘initFormat’:
> warning: ‘numBits’ may be used uninitialized in this function
> >> 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
> > 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...
More information about the build-dev