Xref: utzoo comp.std.c:399 comp.lang.c:12869 Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!pyramid!thirdi!peter From: peter@thirdi.UUCP (Peter Rowell) Newsgroups: comp.std.c,comp.lang.c Subject: Re: C function prototyping and large projects Message-ID: <432@thirdi.UUCP> Date: 22 Sep 88 17:41:11 GMT References: <24@motto.UUCP> <3511@boulder.Colorado.EDU> <1281@micomvax.UUCP> Reply-To: peter@thirdi.UUCP (Peter Rowell) Organization: Third Eye Software, Menlo Park, CA Lines: 54 In article <1281@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >In article <24@motto.UUCP> russ@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