machine generated code and chatty compilers

[Eric Conrad]

>From article <1990Jan11.095715.17262 at gdt.bath.ac.uk>, by exspes at gdr.bath.ac.uk (P E Smee):
> This gets to be a religious argument about the proper task for compilers.

Or a sociological argument.

> My rationale is that the job of a compiler is to take a program source
> as input, and to check it *against the language spec*.  If the source
> is conformant to the spec, the compiler should silently generate the
> appropriate code, as requested by the source generator (be it person, or
> tool).

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.  In the case of
automatically generated code, warnings may not be as significant
because of the need to optimize the target compiler source code.  (I
really don't know if this is an important factor.  I assume that it
must be because of the inclusion of the goto construct in ADA for
similar reasons.)

With warnings off as a default, human users will generally silently
disable warnings by not specifying the warnings option.  Why?  Because
it saves keystrokes.  So for the benefit of human users, I support the
explicit disabling of warnings on the grounds that, if warnings are
disabled, there should be good reason.

Basically then, I feel that a compiler is a software verification
tool as well as a code generation tool.  For example, in ANSI C, it
is legal, for compatibility reasons, to reference functions without
prototypes.  However, doing so increases the likelihood of type
incompatibilities in parameters.  I think that the compiler should
scream unless specifically requested not to.

-- Eric Conrad
+----------------------------------------------------------+
| Eric Conrad - Wright State University                    |
| "Progress was all right once, but it went on too long."  |
+----------------------------------------------------------+