Warning messages

[Frank Adams]

[I have cross posted this to several difference news groups, reflecting
languages where it seems to me to be most immediately applicable - mostly
due to the presence of a "pragma" construct.  Since the examples given are
for the "C" language, I have directed followups there.  Followups concerned
with other specific languages should be directed to the appropriate news
group; those dealing with the idea/problem in general probably belong in
comp.lang.misc.]

Like Mr. Smith, I have come to believe that warning messages from a
compiler are a mistake -- but for a quite different reason, and with
a quite different resolution in mind.

Warning messages are fine for small programs, where one person can
read them all and understand them.  But for a large or medium sized
program, requiring anywhere from three programmers on up, they don't work.
In such a project, one typically has a period "make" or "build", where
all source changed since the last make (sometimes all source) is compiled.
If this compilation is done with warnings enabled, typically many warnings
will be generated -- more than can reasonably be dealt with.

For conscientious software engineers, the solution is to treat warnings as
errors, so that the final program generates no warning messages.  There are
two problems with this.  The first is that the compiler doesn't help: it
returns a "success" return code for a compilation with warning messages only,
so any automated make facility will not detect the error[1].  This problem
occurs even for relatively small projects, which still use a make file.

The obvious solution is to make the compiler treat warnings as errors, and
this is indeed what I am advocating.  But this runs smack into the second
problem: sometimes, the situation being warned about is exactly what you want
to do.

To deal with this, I propose introduction of a pragma, with the syntax:

#pragma permit <keyword>

This pragma would permit the warning condition associated with <keyword> to
be found in the next line, suppressing the error message.  In implementing
this pragma, compilers should follow the following guidelines:

(1) If the keyword is unrecognized, ignore the pragma.  It may be meaningful
to some other compiler.

(2) Similarly, if the keyword is recognized, but the corresponding condition
is not found, do *not* generate any sort of message.  Not all compilers will
define a condition identically, so some other compiler might need the pragma.

(3) The pragma should be associated with the syntactic element most closely
associated with the warning.  For example, many compilers will warn about an
unreferenced local variable at the point where it goes out of scope.  The
pragma should be associated instead with the point where the variable is
declared.

(4) To deal with the automatic code generation problem, there should of course
be a compiler flag to turn off warnings globally.

A partial list of keywords for the C language might include:

assignment - permit an assignment in a conditional context

noeffect - a statement or expression has no effect (for example, "a+b;", or
"a" in "a, b=c").

ambiguous - a statement has ambiguous side effects (on the other hand, I would
be inclined to regard this as simply an error).

unused - a variable is never referenced, or assigned but never used.

uninitialized - a variable is not necessarily initialized at some reference.

unreached - a statement can never be executed.

cast - a nonportable type cast is made (for example, pointer to int).

comparison - a comparison occurs whose value can be determined at compile time.
(Examples include "u<0" and "u<=-1", where "u" is unsigned; or "a==a".)

overflow - overflow occurs in evaluation of a constant expression (including
evaluation of a simple constant).  Note that the next (bignum) condition should
also be suppressed by this keyword.

bignum - a constant occurs which is legal on this machine, but bigger than
the the guaranteed minimum size for its type.  (For example, an int greater
than 32767 on a machine where ints are 32 bits.)

noprototype - a function is called without a prototype in scope.

precedence - don't complain about the use of the default precedence in cases
where that is commonly considered to be confusing (such as "&" and "==").

I would also propose a "#pragma unreachable" which asserts that the point in
the code where it occurs cannot be reached.  This will suppress warnings such
as no return value after a call to "exit" at the end of a function.

-----------------

[1] It would of course be *possible* to build a facility which checks the
compiler output for warning messages, but this requires it to be intimate
with the compiler, and much more complex than is otherwise necessary.