Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ucsd!sdcc6!ix426
From: ix426@sdcc6.ucsd.EDU (Tom Stockfisch)
Newsgroups: comp.lang.c
Subject: Re: Prototypes, was Why NULL is 0
Message-ID: <3644@sdcc6.ucsd.EDU>
Date: 19 Mar 88 03:38:37 GMT
References: <2550049@hpisod2.HP.COM> <7412@brl-smoke.ARPA> <3351@chinet.UUCP> <25652@cca.CCA.COM> <784@cresswell.quintus.UUCP> <25699@cca.CCA.COM>
Reply-To: ix426@sdcc6.ucsd.edu.UUCP (Tom Stockfisch)
Organization: University of California, San Diego
Lines: 38

In article <25699@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes:
>
>	As it stands, the real value of a prototype is informative --
>the calling routine can contain a description of a calling sequence.
>Its value for protecting against erroneous usage of routines is nominal;
>lint is really much more useful.  A prototype declaration does not protect
>you against an incorrect prototype declaration because it does not 'look'
>at the real master (the actual declaration in the code in the called routine)
>whereas lint does.


The prototype DOES protect you against incorrect declaration if you put it
in a header file that is included in BOTH the caller function file AND the
callee function file.  The compiler will then complain of an incompatable
re-declaration if the header file is out of sync with the definition.
This is much preferable to re-linting after every change to a prototype.
It avoids the quadratic behavior of the following sequence:
	
	vi f1.c
	lint f1.c
	cc f1.c

	vi f2.c
	lint f1.c f2.c
	cc f1.o f2.c

	vi f3.c
	lint f1.c f2.c f3.c
	cc f1.o f2.o f3.c

	...

If you cut out the lint, the only remaining quadratic portion is in the loader.
Of course, you'll still want to run lint every great once in a while to check
other things (like conversion of function pointers, or long identifier clashes,
or unreachable code).
-- 

||  Tom Stockfisch, UCSD Chemistry   tps@chem.ucsd.edu