C function prototyping and large projects

[Peter Rowell]

In article <8032 at haddock.ima.isc.com> karl at haddock.ima.isc.com (Karl Heuer) writes:
>The compiler should catch them, if the header which contains the prototype is
>also included in the module that defines the function itself.

As I responded via e-mail to another person, you are *assuming* that:

1. the prototype is in a header which is included by the file which defines
   the procedure.
AND
2. that the dependency in the makefile is such to cause the compiler to
   go recompile the defining module.
   
Although I agree that this is *normally* the case, there are times when
it is not.  I can easily think of some instances of case 1 that would
not have the compiler catch the error.

Minor Flame:  I do *not* understand why people seem to feel that there
is some moral benefit to manual maintenance of information that is
trivially kept correct by automatic means.  If it is OK for the compiler
to "automatically" check these things, what is wrong with creating them
automatically?

What would be *very* useful, productive, etc., etc.  would be an
>environment< that kept track (automatically, of course) of exact
variable/type/procedure dependencies on a per/procedure basis and only
recompiled what was needed.  We have discussed doing this for our own
local consumption but we don't have the time to do it right (at least
not at this time).

Re: your smiley-faced comment at the end.  People who unintentionally
ignore compile dependencies often get nailed.  We *consciously* make
this decision, know what the bugs often look like, and know what to do
if we suspect that it is the case.  We get the benefits of being able
to build a *known correct* set of prototypes + we don't have to pay the
recompile penalty when we know that that is all that changed.

----------------------------------------------------------------------
Peter Rowell
Third Eye Software, Inc.		(415) 321-0967
Menlo Park, CA  94025			...!pyramid!thirdi!peter