Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!bbn!diamond.bbn.com!mlandau
From: mlandau@bbn.com (Matt Landau)
Newsgroups: comp.lang.c
Subject: Re: Subroutine layout in C
Keywords: Here's a couple of handy macros...
Message-ID: <12483@jade.BBN.COM>
Date: 6 Jan 89 18:56:58 GMT
References: <2459@ssc-vax.UUCP> <1987@lznh.UUCP>
Reply-To: mlandau@bbn.com (Matt Landau)
Organization: BBN Systems and Technologies Corporation, Cambridge, MA
Lines: 28

In comp.lang.c (<1987@lznh.UUCP>), ariel@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@bbn.com			  in all this blood and thunder