Subroutine layout in C

Matt Landau mlandau at bbn.com
Sat Jan 7 04:56:58 AEST 1989


In comp.lang.c (<1987 at lznh.UUCP>), ariel at lznh.UUCP (<10000>Ariel Aloni) writes:
>>#define PRIVATE static
>>#define PUBLIC 
>C is terse and accurate, if you want to invent new keywords for C
>please don't abuse CPP, design your own new language.

In general, this is good advice.  If you're going to program in C, then
program in *C*; don't end up with something like the original /bin/sh
code, which no real C programmer ends up wanting to deal with.  But . . .

>In your particular example the change of 'static' is very confusing
>since 'static' has a different meaning for functions and variables.

. . . on the other hand, this is precisely why an alias for "static"
may be a *good* idea.  

One can argue that overloading static with two different meanings was 
a flaw in the original language design -- there does not seem to me to 
be all that much similarity between persistent variables in a function 
and variables/functions that are hidden from other source files, so it's
not clear why you would want to use the same keyword to describe both.

Using something like PRIVATE for file-level static variables or functions, 
and the traditional static for variables that persist across function
invocations, serves to make the distinction clear.
--
 Matt Landau			Waiting for a flash of enlightenment
 mlandau at bbn.com			  in all this blood and thunder



More information about the Comp.lang.c mailing list