[ On Sunday, January 16, 2000 at 23:32:57 (-0500), der Mouse wrote: ]
> Subject: Re: ARGSUSED and friends
>
>    On a few occasions
> lint has helped me too, but I've never gone to the trouble to eliminate
> every last gripe, because some are just too silly (such as the dreadful
> "pointer casts can be troublesome" - franchement, if you can't even
> cast pointers without upsetting lint, it's hard to write anything
> useful.

Without being specific, and certainly not in the sole context of the
specific version of lint available in NetBSD, I would have to generally
say that every "comment" made by a lint is meaningful in some context or
another.  (There, how's that for ambiguity! :-)  Obviously there are
many "comments" made by lint that are not meaningful within a subset of
all of the possible machines C code can be compiled and run on.

>  That's why I use gcc with various warning options instead; I
> find that with a suitable set of options, it's (a) strong enough
> checking to be worthwhile and (b) weak enough that useful programs can
> be made completely warning-free.  (Though I do wish there were a way to
> say "yes dammit I know I have -Wcast-qual on, I really do mean to cast
> away this qualifier"; there are two cases where I commonly want that.)

Indeed lint could use a lot of work in this area.  Finer control over
the target environment it envisions the code running on is something
most of us have been waiting for since 1978 or so, as Steve Johnson's
original paper describing his program alludes to:

         The  central  problem with lint is the packaging of the
    information which it collects.  There are many options which
    serve  only  to  turn  off, or slightly modify, certain fea-
    tures.  There are  pressures  to  add  even  more  of  these
    options.

Personally I believe a *compiler* has no business at all warning me
about some potentially non-portable construct or some code that's not
going to do what I mean it to do so long as it is syntactically correct.
A compiler should compile the code presented to it as quickly and
efficiently as possible.  If you want to do code analysis, strong type
checking, portability checking, etc., then you should do that in a
separate program.  Ideally of course one should use the same syntax
parser to drive both the compiler and "lint", though I guess this less
of an issue these days than it was in the early days of C.  So far as I
know nobody had invalidated Steve Johnson's original conclusions from
his 1978 paper (and indeed others have re-affirmed them, eg. Plan 9,
QNX, etc.):

         In  conclusion,  it  appears that the general notion of
    having two programs is a good  one.   The  compiler  concen-
    trates  on  quickly  and accurately turning the program text
    into bits which can be run; lint concentrates on  issues  of
    portability,  style,  and efficiency.  Lint can afford to be
    wrong, since incorrectness and over-conservatism are  merely
    annoying,  not  fatal.   The  compiler  can be fast since it
    knows that lint will cover its flanks.   Finally,  the  pro-
    grammer can concentrate at one stage of the programming pro-
    cess solely on the algorithms, data structures, and correct-
    ness  of  the program, and then later retrofit, with the aid
    of  lint,  the  desirable  properties  of  universality  and
    portability.

Steve Johnson gave a wonderful talk about the ill-fated history of lint
some years ago (at a Usenix IIRC).  He described all kinds of
interesting things that a lint could do that no compiler alone could so
easily accomplish, things that were only hinted to in his original paper
oh so many years ago.  Unfortunately many of those ideas remain
unimplemented to this day.

Finally, remember as the "Bugs, etc." section of Johnson's original
paper says, "if lint incorrectly complains about something that is
correct, the programmer reports that immediately!"

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>