Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: lint (was: Funny mistake)
Message-ID: <5043@goanna.cs.rmit.oz.au>
Date: 25 Mar 91 04:38:55 GMT
References: <1991Mar22.055335.23091@athena.mit.edu> <13619@helios.TAMU.EDU> <13627@helios.TAMU.EDU>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 25

In article <13627@helios.TAMU.EDU>, byron@archone.tamu.edu (Byron Rakitzis) writes:
> In article <5036@goanna.cs.rmit.oz.au> ok@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.