[Icc-avr] Module globals static?

[Jaspers, Ton]

There are two usages for the keyword "static":

1. On a global variable, to limit the scope of the variable to 
   the current source. If omitted the scope of a global is 
   "external", however other sources need an "external" 
   declaration somewhere. I think it is good practise to export 
   globals in the module's header file. (The "external" 
   declaration is in module's header file) 

2. On a "automatic"  variable. Actually it is no longer an 
   automatic but a static with its scope limited to the function 
   that uses it. 
   
Having a global without "static" and without "extern" has only one 
use, it is listed in the MAP-file. Most linkers won't copy "static" 
globals to the MAP file making it harder to debug.  

A nice use of static in a function context is:

Void Func(void)
{
	static unsigned first = 1 ;

	if ( first )
	{
		first = 0 ;
		do_someting_once() ;
	}

	do_something() ;
}

Above the variable first is turned from automatic (on the stack) 
to static (somewhere in memory) but its scope is still limited to 
within the function. 

I have seen people use EXTERNAL to denote a variable to have 
An external scope:

	#define EXTERNAL	  /* replaced by nothing, for readability only */
	EXTERNAL int some_variable ;

In the module header file:
	extern int ome_variable ;

Personally I never use "extern". I like to treat my modules as 
encapsulated "objects". Variables of a module are accessed through 
"methods"  much like in C++. Obviously these methods are functions. 
It allows me to add range checks and other error handling stuff to 
the "interface" of the module (the interface is obviously a bunch 
of functions). With this approach all globals are declared static 
unless I want them to appear in the debugger. To ease the debugging 
process I use:

	#define STATIC static
or    
	#define STATIC

And:  
	STATIC int some_variable

By changing the #define, all globals become visible in the debugger.


Hope this helps,
Ton


> -----Original Message-----
> From: icc-avr-bounces at imagecraft.com 
> [mailto:icc-avr-bounces at imagecraft.com] On Behalf Of Bengt Ragnemalm
> Sent: woensdag 24 oktober 2007 14:44
> To: 'Discussion list for ICCAVR and ICCtiny Users. You do NOT 
> need tosubscribeto icc-announce if you are a member of this.'
> Subject: SV: [Icc-avr] Module globals static?
> 
> Do you mean that there is a difference between declaring a 
> global variable with and without the static operand?
> 
> Is there in this matter any difference in a global variable 
> defined in the same file as main and a global variable in 
> another file? (I call these module global). I know that a 
> variable that is defined global in another file will only be 
> seen by functions in that file.
> 
> The way you write make me think that if I write static to a 
> file global variable will not make it totally global but not 
> static will.
> 
> /Bengt
> 
> > -----Ursprungligt meddelande-----
> > Från: icc-avr-bounces at imagecraft.com [mailto:icc-avr- 
> > bounces at imagecraft.com] För David Brown
> > Skickat: den 24 oktober 2007 11:45
> > Till: Discussion list for ICCAVR and ICCtiny Users. You do NOT need 
> > tosubscribe to icc-announce if you are a member of this.
> > Ämne: Re: [Icc-avr] Module globals static?
> > 
> > Bengt Ragnemalm wrote:
> > > Is a variable that is global in a module also 
> automatically static? 
> > > I think it is but if so, shouldn't the strictly most 
> correct way to 
> > > define the globals also be as static?
> > >
> > >
> > 
> > Yes, global variables are statically allocated, meaning they have a 
> > fixed address in memory (assigned by the linker) and exist 
> throughout 
> > the lifetime of the program.
> > 
> > You can think of the keyword "static" as having two 
> distinct effects 
> > on variables - it ensures that they have a statically allocated 
> > address, and it ensures that they have the minimum possible scope.  
> > Thus all file-level data and functions should be declared "static" 
> > unless you are specifically defining global data or functions that 
> > should be available from other files.
> > 
> > mvh.,
> > 
> > David
> > 
> > _______________________________________________
> > Icc-avr mailing list
> > Icc-avr at imagecraft.com
> > http://dragonsgate.net/mailman/listinfo/icc-avr
> 
> 
> _______________________________________________
> Icc-avr mailing list
> Icc-avr at imagecraft.com
> http://dragonsgate.net/mailman/listinfo/icc-avr
>