Check the Arg Count (really lint libraries)

[Dave Brower]

In article <1887 at utah-gr.UUCP> donn at utah-gr.UUCP (Donn Seeley) writes:
>Brett Galloway complains:
>	...  [Lint] 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. ...
>
>Lint (under BSD Unix and probably most other varieties) works exactly
>like cc, 'compiling' into an intermediate form and 'loading' the
>result...

This is true in the simple case, and Donn's posted shell script will help
create libraries for those without the SV lint that has the -c option.

Unfortunately, the big problem is that lint libraries so conceived do
not have anywhere near the same semantics as the "equivalent" object
libraries.  Lint pass 2 can't selectivly load a module as is done by the
linker.  This can really complicate matters on large systems where many
executables are built from the same libraries without really using all
of the contents of the whole library.

Conjecture:

Would life be easier in this case if every .c file compiled into a library
had the magic /*LINTLIBRARY*/ comment?

-dB

-- 
	Kill Tree.	Kill Turkey.	Merry Xmas.

{amdahl, sun, mtxinu, cbosgd}!rtech!daveb