Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Warning messages
Message-ID: <15642@haddock.ima.isc.com>
Date: 12 Jan 90 21:12:15 GMT
References: <1471@mdbs.UUCP> <2NNQZ%@rpi.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 58

In article <2NNQZ%@rpi.edu> adamsf@turing.cs.rpi.edu (Frank Adams) writes:
>...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.

Of the constructs that produce warnings from Unix C compilers (including
lint), most can be disabled with a slight rewrite at no cost to performance.
I expect this is true of non-Unix compilers too, though I have less experience
there.

>assignment - permit an assignment in a conditional context

I would prefer rewriting it as an explicit compare against zero.

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

So why not add the "redundant" parens instead of a pragma that says you know
what you're doing?  See _The Elements of Programming Style_ for the example
where a user deliberately omitted an optional keyword (an "else" or "end" or
something; I don't know PL/I) and tossed in several lines of commentary to
explain why it was kosher to do so.

>noeffect ... unused ... unreached ...

If the conditions for such dangling code/declarations can be determined (not
always easy, I admit), you can simply |#if| them out.

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

Under what conditions is it desirable to invoke a function without a
prototype?

>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.

Better would be a |#pragma nonreturning| that could be attached to the
*declarations* of functions like |exit()|.  Then you only need to specify them
once per function, rather than once per use.  |#pragma unreachable| may still
have some uses, though.

I'd like to suggest some additions:

aligned - attached to the declaration of a function like |malloc()| to inform
the compiler that it's *always* safe to cast this to any pointer type (note
that |void *| does *not* include such a guarantee).

fallthrough - (at the end of a case, just before the next case label) the
absence of a |break| here is intentional.

monomorphic - the arguments covered by the ellipsis in this prototype will all
have the same type as the last declared argument (e.g. for |execl|).  this
pragma would normally *add* opportunities for warnings (e.g. when the user
forgets to cast the NULL that terminates the list).

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint