machine generated code and chatty compilers

[Art Boyne]

econrad at thor.wright.edu (Eric Conrad) writes:

>I would argue that, in order to assure better quality code, human coders
>should compile with warnings enabled.  I have yet to see a compiler
>issue warnings that should not be investigated.

The problem is: once you *have* investigated the warnings, how do you
get the compiler to *shut up* on an individual warning in future compiles?
I don't want a global shut-up flag, even on a particular class of errors,
because, in the course of modification, I still might make that class of
error.  Lint does have some comment-directives to tell it to not flag
individual instances of questionable code; ought not the compiler have the
same feature?

Example:  we build instruments at this site, and use a standard parser for
interpreting instrument commands.  It calls all execution routines with
three arguments: input parameter list ptr, output result list ptr, and a
miscellaneous ptr (ie. *in, *out, *misc), where either *in or *out or both
may be null, depending on the command.  Well, that means a lot of routines
never use at least one of the input parameters, and our lousy chatty compiler
generates warnings for *each* unused parameter in *each* routine.  Needless
to say, it is easy to miss a new warning amidst the (numerous) old.

Art Boyne, boyne at hplvla.hp.com