William "Chops" Westfield wrote:

> On Mar 10, 2008, at 3:49 AM, Alan B. Pearce wrote:
> 
>> You mean that the reviewers do not use Lint
> 
> Don't modern C compilers check for and report most of the errors that  
> LINT used to be used to catch?  

Probably a number of them are the same, but the focus of compiler warnings
is quite different from tools like lint. 

> I know that every time we upgrade our compiler(s) (mostly gcc), we have
> significant numbers of non-bugs to "fix" just to make the compiler happy

I generally bump up the warning level of the compiler and then "code
around" the warnings to make them disappear in the way the compiler wants
it. Usually, this is not more work than the comments I'd have to add anyway
to explain why strange things are being done in the code -- with the added
benefit to get the warning where the strange thing is being done by
accident rather than on purpose.

> USUALLY mitigated by the set of very real bugs it finds with the same
> checks, 

That's exactly the point.

> with open source software, one is very much at the whims of whoever is
> working on the code, and it's AMAZING how much is not clearly defined in
> specifications.

Well, not only with OSS, I think. Warnings are in general not defined by
standard committees; they are raised when something that is possible
(according to the language definition) but possibly not what you want is
found. This is by definition subjective. 

Where a warning is raised but you have made sure that everything is in fact
ok, there is (or better, should be) a way to make the warning go away
without changing the generated code. This then also serves as the
documentation I mentioned above, telling the reader that a generally
doubtful practice in this location is ok and has been reviewed
specifically.

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist