From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.c:25024 comp.lang.c++:6105 comp.lang.ada:3158 comp.lang.misc:3865 Path: utzoo!censor!dybbuk!yunexus!ists!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!turing.cs.rpi.edu!adamsf From: adamsf@turing.cs.rpi.edu (Frank Adams) Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.ada,comp.lang.misc Subject: Warning messages Summary: should be errors Keywords: large projects Message-ID: <2NNQZ%@rpi.edu> Date: 12 Jan 90 02:44:47 GMT References: <1471@mdbs.UUCP> Reply-To: adamsf@turing.cs.rpi.edu (Frank Adams) Followup-To: comp.lang.c Organization: RPI CS Dept. List-Id: [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 This pragma would permit the warning condition associated with 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.