Path: utzoo!mnetor!uunet!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Prototypes, was Why NULL is 0
Message-ID: <25747@cca.CCA.COM>
Date: 19 Mar 88 22:20:00 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> <3644@sdcc6.ucsd.EDU>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 66

In article <3644@sdcc6.ucsd.EDU> ix426@sdcc6.ucsd.edu.UUCP (Tom Stockfisch) writes:
>
>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.

	Do I understand this correctly to mean that you may have a
prototype in the header, and in the caller body proper, and a declaration
in the callee, and that all is okay as long as every thing matches?  I
ask, in part, because I don't know.  This does work both for protection
and for information (visibility in the code of the declaration).  There
are the usual problems that the declarations must, in fact, be there, and
that all make files contain all relevant dependencies.  That, however, is
another matter.

>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

	Er, that does seem like an odd way to do things.  If I have ten
files to alter, I would edit all ten files first, lint them together, and
compile them together.  Or, if the change were complex in the individual
files perhaps

	vi prototypes.h

	vi f1.c   <--|    (Edit and lint until f1.c passes preliminary
	lint f1.c ---|    lint testing to remove trivial errors and typos)

	Repeat above loop for compiles, until compiler does not complain

	Repeat above process for all files

	Lint run when all files are processed.

	Link and initiate testing.

I may be missing something, but I do not see the point of linking corrected
and uncorrected code as a matter of routine policy.

>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).

	Well, I find it useful to run lint on individual files when I make
big changes to them -- unfortunately I sometimes make typos, mistakes about
types, and other errors like that.  I like to catch as many of these things
before I start serious checking.  Other people may not need to.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.