Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!hplisa!hplvli!boyne
From: boyne@hplvli.HP.COM (Art Boyne)
Newsgroups: comp.lang.c
Subject: Re: machine generated code and chatty compilers
Message-ID: <340016@hplvli.HP.COM>
Date: 17 Jan 90 16:26:15 GMT
References: <1471@mdbs.UUCP>
Organization: Loveland Inst. Div
Lines: 24

econrad@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@hplvla.hp.com