WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: [Xen-API] [PATCH] imported patch removing-warnings

On 10/11/10 15:30, Dave Scott wrote:
My quick comments are: 1. a lot of warnings will be attributed to the
"xen hg user" (have a look at "hg export 0")

The "xen hg user" should be held responsible for his actions.

2. as a special case, it might be good to view fixing warnings as a
task for newbies to help familiarise them with the codebase. I would
agree with the notion that henceforth, new warnings should be treated
as bugs and the creator should tidy them up.

One way that we could do this is to enable the "treat warnings as
errors switch". However, we can't do this yet, due to the rather
high number of existing warnings in the code. As such it's also
very difficult to spot the emergence of new warnings, as they tend
to get swamped out in all the noise.

A fresh run of "make" shows the following counts for each category:

    bad source file name                                2
    this argument will not be used by the function     10
    this expression should have type unit             105
    this match case is unused                           6
    this pattern-matching is not exhaustive            65
    this sub-pattern is unused                          3
    this statement never returns                        2
    unused variable                                   131

I'd be in favour of (some variant of) Rok's idea:

  * organise a concerted drive to get rid of all warnings, and then
  * permanently enable the "treat warnings as errors" compiler flag.

If we did decide to do this, then two questions spring to mind:

  1. As a team, how can we quickly and efficiently remove all the
     warnings, without introducing more errors into the code base?

     As an example of the care that we'd need to take, we wouldn't
     want to simply remove all assignments to unused variables, as
     we'd need to make sure that we're not relying on side-effects
     from RHS-expressions.

  2. When should we do this?

Thoughts? :)
Jonathan

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api