tags:

views:

209

answers:

5

Hi Experts,

Is it possible to declare multiple static variables of same name in a single C file with different scopes? I wrote a simple programme to check this and in gcc it got compiled and worked fine. code:

static int sVar = 44;

void myPrint2()
{
    printf("sVar = %d\n", sVar++);
}


void myPrint()
{
    static int sVar =88;
    printf("sVar = %d\n", sVar++);
}

int main(void)

{

    static int sVar = 55;
    int i = 0;
    for (i = 0; i < 5; i++)
        myPrint();      
    printf("sVar = %d\n", sVar);
    myPrint2();
    return(0);
}

Now my question is since all "static" variable will reside in same section (.data) then how we can have multiple variable with same name in one section? I used objdump to check the different section and found that all Static variables (sVar) were in .data section but with different names

0804960c l O .data 00000004 sVar

08049610 l O .data 00000004 sVar.1785

08049614 l O .data 00000004 sVar.1792

Why compiler is changing the name of variables (since C doesnt support name mangling)?

Thanks in advance.

+6  A: 

A function-local static variable is something different than a global static variable.
Since there can be as many function-local statics with the same name as you like (provided they are all in different functions), the compiler might have to change their names internally (incorporating the function's name or the line number or whatever), so that the linker can tell them apart.

sbi
That is true but both local and global static variable are residing in same data section and since you cant have multiple variables of same name in same data sections therefore I believe compiler is changing the name. Please correct me if I am wrong.Thanks
Mohammed Khalid Kherani
@Mohammed: The way I understand you, you have just repeated my second sentence. Why should I disagree with that? `:)`
sbi
Ya true..:) Is it mean C compile also support name mangling??
Mohammed Khalid Kherani
It can mangle the names here (into invalid C names) because it can expect that no other object file will refer to them. The linker needs them only so that it can resolve the relative memory accesses when the data section is given a fixed address at load time.
Tim Schaeffer
+2  A: 

Your first sVar is global to file, second one is local to the function myPrint() and third one is local to main()

Function level static variables are not accessible outside the function - they just retain their values on subsequent calls. I assume you've already noted this when you ran your code.

Amarghosh
+1  A: 

Block scoping. Read K & R.

xcramps
+1  A: 

The static keyword has different meanings when it's global and local, the first sVar is just a global variable unavailable to other translation units. And static variables sVar in myPrint() and main() are in different scopes, so they are different variables. In the body of myPrint() sVar refers to the local static (hiding global sVar), in myPrint2() it refers to the global (it's not hidden by anything local), and in main() it refers to the local static sVar, which again hides the global since the moment it was declared.

Michał Trybus
+1  A: 

There is a difference between visibility and extent; also, the static keyword has different meanings based on scope.

Adding the static keyword to the block scope versions of sVar (myPrint::sVar and main::sVar) changes their extent (lifetime), but not their visibility; both are visible within their respective functions only, and will shadow or hide the file scope version within their local scope. It indicates that the variables have static extent, meaning the memory for them is allocated at program start and held until the program terminates (as opposed to automatic or local extent, where their lifetime is limited to the scope in which they are defined).

Adding the static keyword to the file scope version of sVar doesn't change its extent (file scope variables have static extent by definition), but it does change its visibility with respect to other translation units; the name is not exported to the linker, so it cannot be accessed by name from another translation unit. It is still visible within the current translation unit, which is why myPrint2 can access it.

John Bode