Check the Arg Count

[Brett Galloway]

In article <1193 at ucbcad.berkeley.edu> faustus at ucbcad.berkeley.edu (Wayne A. Christopher) writes:
>In article <4900 at mimsy.UUCP>, mangoe at mimsy.UUCP (Charley Wingate) writes:
>> You still haven't explained why lint as a processor should be logically and
>> functionally distinct from cc as a processor.  The ONLY reason I can see for
>> separating them is so that you don't have to be confronted with messages
>> telling you that you're writng tricky or otherwise dubious code.
>
>Most of the things lint points out either aren't available to ccom, or
>are definitely not appropriate.  How is ccom going to know what is in
>the other files that I'm going to link with?  Detection of incompatible
>arguments, return values, etc across modules is lint's most useful
>function.

Wayne's first point is the strongest -- ccom CAN'T know anything about
source files outside of the one at hand.  Lint can.  I do, however, have
a gripe about lint (at least about 4.2bsd lint).  It provides the ability
to create lint libraries.  Unfortunately, lint treats these libraries
differently than cc treats object libraries.  It would be most useful for
maintaining large pieces of software if lint behaved the same as cc --
lint'ing source files into some intermediate form, finding all lint errors
unique to that source file (this is analogous to the compile cycle), and
lint'ing the intermediate lint files together to find global errors (this
is analogous to the load cycle).  This would make lint easier to
use, especially from within makefiles.  If lint were easier to use, it
might be used more extensively.

-- 
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett