C function prototyping and large projects

Peter Rowell peter at thirdi.UUCP
Fri Sep 23 03:41:11 AEST 1988


In article <1281 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:
>In article <24 at motto.UUCP> russ at motto.UUCP (Russell Crook) writes:
>>We are just starting to use function prototypes, and are looking for
>>suggestions on how to use them.
>>....
>>Do you regenerate the prototypes automatically, every time you rebuild
>>or whenever the source file changes, or what?
>
> ...
>
>The answer to the automatic *generation* question is simple - do it once if
>your code has not used prototypes before (this is why MS provided the
>feature), disseminate the output into header files, then maintain the
>information manually as you would for any other global information.
             ^^^^^^^^
My experience shows that manual maintenance of this type of information,
if done incorrectly, can lead to bugs that are incredibly difficult to
find - particularly when the parameter types are used for doing
automatic coercion, as specified for ANSI C.

Our solution is (and has been for many years) to completely automate
the generation of prototypes and general external information.  Some
languages/environments may support some or all of this process, but
we have found portability requires we "roll our own".

Using two new "keywords" (export and exportdefine) and a variety
of shell and sed scripts, we regularly "re-edit" .h files so that
they contain the latest definitions of constants, macro routines,
global variables, functions and type information.  Appropriate
dependencies are maintained via our version of "make depend" -
both for when the .h's need to be rebuilt and for when .c's need
to be recompiled.

During intense development cycles there can be quite a bit of
unnecessary reebuilds/recompiles, so we kill the dependencies and
depend on programmer knowledge of probable side effects.  Every once in
a while this fails and you get a weird bug, but then we do a "forced"
rebuild of the universe and that normally fixes everything.  Code
shipped to customers always has full dependency information.

We have discussed building a more knowledgable dependency system where
.c files would be made explicitly dependent on each (implicitly or
explicitly) imported value/variable/procedure/type.  Although I know
we will do this eventually, we are trying to get alpha 1.2 out the door,
and we just don't have the time (I'm sure everyone else has oodles of time
for stuff like this :-).

Anyone wishing the actual sed/shell/.h files can email me at
...!pyramid!thirdi!peter.

----------------------------------------------------------------------
Peter Rowell		"Gee, Dr. Science, can we depend on that prototype?"
Third Eye Software, Inc.		(415) 321-0967
Menlo Park, CA  94025			...!pyramid!thirdi!peter



More information about the Comp.std.c mailing list