lint (was: Funny mistake)

[Richard A. O'Keefe]

In article <13627 at helios.TAMU.EDU>, byron at archone.tamu.edu (Byron Rakitzis) writes:
> In article <5036 at goanna.cs.rmit.oz.au> ok at goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> >But will your hand-holding compiler check that a *group* of files are
> >consistent?  That's what I really depend on lint for.

> I don't see what you need over and above good function-prototype checking.

But how do you check that the prototypes used in file FOO.C agree with
the function definitions in file BAZ.C?  If the programmer makes a habit
of #including the header files with the prototypes _both_ in the files
that use things _and_ in the files that provide them, all is well.  If
not, and there is nothing in ANSI C to require it, we're back in the
realm of Pascal, i.e. up the well known creek without a paddle.

> I am going to write a compiler strongly biased towards ANSI C; if you don't
> supply prototypes, you will pay the price of not having the use of
> unprototyped functions checked for type safety.

Ah, I _see_.  Only people who are willing to rewrite all their old code
and make it non-portable to pre-ANSI systems (still in very wide use)
will benefit.  You know, you _could_ help people who have to maintain
old code by adding to your compiler an option to write prototypes
inferred from the definitions out to a file.
-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.