Prototypes local or global opinions wanted
Steve Summit
scs at adam.mit.edu
Thu Jun 27 01:30:26 AEST 1991
In article <phil.7968 at phd.UUCP> phil at phd.UUCP (H Phil Duby) writes:
>In article <1991Jun21.004933.4197 at athena.mit.edu> scs at adam.mit.edu (Steve Summit) writes:
>> Most certainly. If prototypes are used, they MUST be placed in
>> header files...
>
>If the function you want to prototype (VERY good idea IMHO) is used by a
>set of other functions that can be convienently grouped together into a
>single source file, seperate from other functions that should not call the
>function, declare the prototype global in that source file, but with the
>static qualifier.
Phil is quite correct. I forgot this exception when I made my
blanket statement; a static prototype does belong in the same
source file where the function is defined and used.
>For purists who insist prototypes should also be declared in a header file...
>use the (also talked/beaten to death) option of
>putting #ifdef #endif pairs around the prototype (with or without the
>static qualifier), and provide the appropriate define only in the source
>file(s) that SHOULD be calling the function.
I hope Phil didn't get the impression I was that kind of a purist --
blindly putting static prototypes in header files just because of
some silly rule would be, well, silly.
Using private #ifdefs in public header files is mildly ugly, and
should only be resorted to when the private declarations must be
shared by a group of "private" files which for some reason cannot
be combined into one file, such that the static storage-class
cannot be used.
(Note, by the way, that a header-file declaration for a static
object or function, if such a declaration is used at all, should
also have the static storage-class, because the ANSI standard
says that the first declaration seen must agree with the
definition with respect to the presence or absence of the static
storage-class. This is another old and tired topic, which I am
not suggesting that we reopen.)
Steve Summit
scs at adam.mit.edu
More information about the Comp.lang.c
mailing list