warnings

[Ray Lehtiniemi]

On Thu, Sep 02, 2004 at 09:14:17PM -0400, Adam Jackson wrote:

> I don't really care much either way as long as good patches get merged, but I 
> do get a warm fuzzy from seeing bug numbers in front of commit messages.  I 
> suppose the mythical Xjanitor people will need to come up with a process and 
> stick to it ;).

mythical?  i was wondering about that... :-P  so who all is part of
the xjanitor team at the moment?


> Seriously, who wants to act as patchmonkey for janitorial patches?  I'm 
> willing to do it if no one else steps forward, but in a larger sense the 
> janitation project needs a a set of goals and tasks, and I'm probably not the 
> guy to come up with them.

well, if i was to take a stab at setting a list of tasks, i'd probably
say this (not knowing much at all about the codebase in question, but
what the hell... all janitorial work is pretty much the same, right? :-)


 - get rid of all the "easy" warnings
   - ansification warnings
   - unused vars
   - suggest parens
   - might be used uninitialized
   - implicit declarations
   - etc

 - crank up the compiler to -W -Wall

 - clean up all the new "easy" warnings
   - whatever they are..

 - remove or justify with comments all uses of keywords
   - register
   - volatile

 - find all uses of #include "something.c" and fix

 - indentation
   - pick a standard set of arguments
   - create a shell script with those args
   - use it to reindent everything
   - make sure all checkins from that point forward use it

 - generate header file with canonical macros for common things
   - MAX()
   - MIN()
   - countof()
   - etc

 - fix the "hard" warnings if possible/desirable
   - taking address of a label
   - goto *expr
   - etc

 - pick one or two of these, remove the rest, and fix breakage
   -D_POSIX_C_SOURCE=199309L
   -D_POSIX_SOURCE
   -D_XOPEN_SOURCE
   -D_BSD_SOURCE
   -D_SVID_SOURCE
   -D_GNU_SOURCE

 - start working on deprecated code
   - make a hit list of deprecated subsystems
     - with plans for removing each one
     - and order the list
   - #define __deprecated __attribute__((deprecated)) // for gcc that supports it, else leave empty
   - for each deprecated system
     - tag all deprecated functions/vars/types with __deprecated
     - for each user of the system
       - remove dependency on the subsystem
     - remove subsystem

 - visibility cleanups
   - for each function/variable in each c file
     - make sure anything that can be marked static is
     - make sure everything else has an extern prototype declaration
       in an appropriate header file

 - const stuff
   - for each function in each c file
     - tag function parms with const as appropriate
     - if applicable, tag function with
       - __attribute__((pure))
       - __attribute__((const))

 - since we're groveling over every single file anyway
   - clean up any hungarian notation that might have wormed its way in

 - do a survey of precompiler abuse
   - catalog #define macros
     - replace with inlines where justified
   - catalog #ifdefs
     - come up with a plan of attack for reducing ifdefs

 - header file cleanups
   - build a tree to visualize nested header inclusion
     - break some of the deepest roots of the tree
   - make sure all header files can be compiled in isolation
     - add appropriate type declarations
   - remove unneeded header inclusions from c files
 
 - go through http://people.redhat.com/drepper/dsohowto.pdf
   - implement all relevant DSO optimizations

 - look at autoconfiscating the whole thing?
   - kill imake
   - kill makedepend
   - etc

 - security
   - get input from the OpenBSD people regarding security audits
   - implement their recomendations



comments?

-- 
----------------------------------------------------------------------
     Ray L   <rayl at mail.com>