C function prototyping and large projects

[will summers]

In article <1281 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:

RD> Continually re-generating prototypes can only lead to trouble, does not
RD> adequately separate "static" and "extern" declarations, and doesn't
RD> automatically get the information into the correct places.

Segrating statics is not a problem as long as the generator makes
a distinction between these (either has an option to only generate
for "extern"s or carries the distinction to the output).  What other
"trouble" can it lead to?

RD> Define things as global only on a "Need to know" basis - i.e. put static
RD> in front of everything in sight!  (:-)/2

Hear Hear!!

RD> Hopefully prototyping will increase the diligence of using that little
RD> word "static" when defining procedures which do not *need* to be global

Many will sneer, but my local "universal" include contains:

#define public /* nothing */
#define private static

'static' only gets used for storage duration, 'private' for linkage.

Consistently using 'public' serves 3 purposes:
   1>  It makes it easier for automatic header generators to find the publics.
   2>  It removes the temptation to take the shortcut of leaving the linkage
       unspecified when the function really should be 'private'.  In other
       words it forces a decision to be made and puts the public and
       private choice on even footing...
   3>  Closely related to <2>, it informs the reader that I -choose- to make
       the function/variable public and it is in fact used in other files 
       (ie. check other files before mucking with it).

    \/\/ill <tm>


--  
St. Joseph's Hospital/Medical Center - Usenet <=> FidoNet Gateway
Uucp: ...{gatech,ames,rutgers}!ncar!noao!asuvax!stjhmc!18.6!will.summers