where are static values stored?

Given the following code:

Code:

---

#include <stdlib.h>
#include <stdio.h>

int do_something(char *);

int
main(int argc, char *argv) {

  char *c = malloc(sizeof(char));
  *c = 'c';

  do_something(c);
  do_something(NULL);

  return 0;

}

int
do_something(char *value) {

  static char *c;

  if (value) {
    c = value;
  }

  printf("%c\n", *c);

  return 0;

}

---

Is the address of the variable c inside do_something stored on the heap, stack, or in a different location in memory? How does the program know to reference the same address/value when the function is called a second time?

Variables local to a scope are normally destroyed at the end of a statement block. The lifetime of the object is also over, meaning that the stack is popped and memory is physically returned to some sort of pool, or the operating system (whatever the case may be.)

The only real difference a static variable has from a normal variable is that the lifetime of the variable doesn't end with its' scope, it's value still exists somewhere in memory. When you first call a function with a static variable, the initialization will be performed, but performed not again if the function is recalled. Access is also restricted to places where you can give that value a name.

It's up to compiler implementors to implement this behavior. I suppose a lot of things could work, like copying a static variable off the stack and silently moving it elsewhere when it's scope has ended. But it's most likely kept in the same memory globals are, as this is possible:

Code:

---

#include <stdio.h>
#include <assert.h>
void funcio( void );

int * p;

int main ( )
{
    funcio();
    assert( *p == 42 );
    return 0;
}

void funcio ( void )
{
    static int d = 42;
    p = &d;
}

---

[edit] Oh and, also, the name of a static variable is included in the compiler's symbol table when you build. That's how it remembers what the "special" value is, even if you have another variable with different lifetime semantics. [/edit]

Clearer now?

Quote:

---

Originally Posted by citizen

Variables local to a scope are normally destroyed at the end of a statement block. The lifetime of the object is also over, meaning that the stack is popped and memory is physically returned to some sort of pool, or the operating system (whatever the case may be.)

The only real difference a static variable has from a normal variable is that the lifetime of the variable doesn't end with its' scope, it's value still exists somewhere in memory. When you first call a function with a static variable, the initialization will be performed, but performed not again if the function is recalled. Access is also restricted to places where you can give that value a name.

It's up to compiler implementors to implement this behavior. I suppose a lot of things could work, like copying a static variable off the stack and silently moving it elsewhere when it's scope has ended. But it's most likely kept in the same memory globals are, as this is possible:

Code:

---

#include <stdio.h>
#include <assert.h>
void funcio( void );

int * p;

int main ( )
{
    funcio();
    assert( *p == 42 );
    return 0;
}

void funcio ( void )
{
    static int d = 42;
    p = &d;
}

---

[edit] Oh and, also, the name of a static variable is included in the compiler's symbol table when you build. That's how it remembers what the "special" value is, even if you have another variable with different lifetime semantics. [/edit]

Clearer now?

---

Well here is my tuppence worth....firstly in my opinion static variables are 'normal' variables
it is the other type of variables which are 'abnormal' :D
Anyway thats immaterial really, apart from the disavantage 'unstatic variables' have if you
are trying to debug a program and you want to see what the value of that variable was
but can't because it no longer exists.

But back to the point in question, I don't think the variable is question is a variable, I think it
just tells the compiler that that function returns an integer, thats all, nothing more.
So.....it would only exist temporilary on the stack when the function had been called and
was returning it's return value, so it is really a dynamic variable.

I could be wrong on this, but have I ever been wrong in the past? ;) (don't bother answering that ).

Quote:

---

But back to the point in question, I don't think the variable is question is a variable, I think it
just tells the compiler that that function returns an integer, thats all, nothing more. [...] it would only exist temporilary on the stack when the function had been called and
was returning it's return value, so it is really a dynamic variable.

---

I don't want to claim that the compiler wouldn't optimize my snippet in the crude manner that you implied; however my snippet is not "in question." I was demonstrating my answer: That statics are stored in the same place as globals with access restrictions. My snippet was more of a test to see if you could globally poke at the value of something static. Had you not been able to, the assertion should have failed, (like it would for a pointer to a local automatic variable).

What you later stated is a possibility, but static variables cannot be destroyed at any point in run time (as dynamic ones can). As I stated, statics could be copied around from the function stack like you said. But the lifetime of the static variable is well defined, unlike a dynamic one: as long as from the point of initialization to the termination of your program. There's no need to explicitly manage static memory, and although implementors may opt to do that behind the scenes, I don't think that is the case for many. Personally, I wouldn't do it that way.

OP: c will live just as I described but it may point to other places in memory that make c invalid.

Quote:

---

Originally Posted by citizen

I don't want to claim that the compiler wouldn't optimize my snippet in the crude manner that you implied; however my snippet is not "in question." I was demonstrating my answer: That statics are stored in the same place as globals with access restrictions. My snippet was more of a test to see if you could globally poke at the value of something static. Had you not been able to, the assertion should have failed, (like it would for a pointer to a local automatic variable).

What you later stated is a possibility, but static variables cannot be destroyed at any point in run time (as dynamic ones can). As I stated, statics could be copied around from the function stack like you said. But the lifetime of the static variable is well defined, unlike a dynamic one: as long as from the point of initialization to the termination of your program. There's no need to explicitly manage static memory, and although implementors may opt to do that behind the scenes, I don't think that is the case for many. Personally, I wouldn't do it that way.

OP: c will live just as I described but it may point to other places in memory that make c invalid.

---

Well my point is basically that the question is a false one, he is not declaring a static
variable in this case, merely informing the compiler that the function returns an integer.

It's a fairly academic question to me anyway, my use of passing variable back and forth
between functions is somewhat 'limited' shall we say.

And in answer to the OP question, when function is called a second time it merely
retrives the return value of the stack as it did in the first call.

I mean how could you access this static variable any way?

Code:

---


int somevariable;

somevariable=do_something;

---

That is, I am fairly sure going to return an error similar to:-
"Oi!! you cannot do that, incompatible types, somevariable is an integer and do_something is a pointer to a function.

You *might* get away with:-

Code:

---


int somevariable;

somevariable=(int)do_something;

---

But I can't see it being of any use.

Quote:

---

Originally Posted by esbo

"Oi!! you cannot do that, incompatible types, somevariable is an integer and do_something is a pointer to a function.

---

This is not a way to call a function in C. If you do not know this bit of info about C - why you still trying to answer any question here?

You just confusing people with such a crap.

Quote:

---

Well my point is basically that the question is a false one, he is not declaring a static
variable in this case, merely informing the compiler that the function returns an integer.

It's a fairly academic question to me anyway, my use of passing variable back and forth
between functions is somewhat 'limited' shall we say.

---

But the pointer is a static variable, and he doesn't seem to be using functions in any sort of awkward way (admittedly I'm losing track of what you really are saying).

Just because he is not taking advantage of the fact that the value is alive for the whole program in this particular snippet, doesn't mean that he wouldn't take advantage in a real project. Static variables are like globals, but because they have scope, it can be easier to locate where errors happen. Some statics aren't even constant: some counters could be static (as in, maybe, reference counters in C++).

Quote:

---

I mean how could you access this static variable any way?

---

That being the point: you use a static variable while it is in scope; it sits there otherwise. Anything that might happen, such as passing the value of a static variable to another function, is pretty seamless because you are passing by value. It's more to the point that a static variable has it's value preserved.

The rest of your statements are irrelevant. No one is using the functions we've written in the manner you describe.

Quote:

---

Originally Posted by esbo

Well here is my tuppence worth....firstly in my opinion static variables are 'normal' variables
it is the other type of variables which are 'abnormal' :D

---

Yes, in your view and not any sane programmer's view.

Quote:

---

Anyway thats immaterial really, apart from the disavantage 'unstatic variables' have if you
are trying to debug a program and you want to see what the value of that variable was
but can't because it no longer exists.

---

The advantage with non-global variables is that they are destroyed at the end of the function and hence it they cannot interfere with any other code because they exist no longer, unlike global variables whose state can be modified anywhere and can contain bad data.

Quote:

---

But back to the point in question, I don't think the variable is question is a variable, I think it
just tells the compiler that that function returns an integer, thats all, nothing more.
So.....it would only exist temporilary on the stack when the function had been called and
was returning it's return value, so it is really a dynamic variable.

---

It is a static variable, whether you like it or not. In release, the compiler might optimize it, but it is still a static variable and nothing else.

Quote:

---

I could be wrong on this, but have I ever been wrong in the past? ;) (don't bother answering that ).

---

I'm going to do it anyway.
You've been wrong and proved wrong countless times, yet you do not listen.

Right, do go back to the original question:
a static variable has all the same properties as a global variable, EXCEPT it is not visible outside it's current scope.
This means that a static variable declared within a function is not visible outside that function.
A static variable declared outside of a function is visible to this file[1] only.

[C++ has further extensions to the meaning of static, where static means that the member function or member variable is accessible/exists even when there is no object in itself.]

[1] Technically, "the compile unit", as in the source file given to the compiler, and any files included within that file.

--
Mats

Quote:

---

Anyway thats immaterial really, apart from the disavantage 'unstatic variables' have if you
are trying to debug a program and you want to see what the value of that variable was
but can't because it no longer exists.

---

They're called "auto" variables, after the keyword of the same name. Besides, you can see the value of automatic variables inside different functions if you need to, in the call stack. If you tried to see variables outside the call stack, you wouldn't get very meaningful values.

Code:

---

C>type viewvar.c
#include <stdio.h>

void func() {
    puts("In func()");
}

int main() {
    int mainvar = 3;
    func();
    return 0;
}

C>gdb -q viewvar.exe
(gdb) break viewvar.c:4
Breakpoint 1 at 0x401296: file viewvar.c, line 4.
(gdb) r
Starting program: viewvar.exe

Breakpoint 1, func () at viewvar.c:4
4          puts("In func()");
(gdb) bt
#0  func () at viewvar.c:4
#1  0x004012da in main () at viewvar.c:9
(gdb) frame 1
#1  0x004012da in main () at viewvar.c:9
9          func();
(gdb) l
4          puts("In func()");
5      }
6
7      int main() {
8          int mainvar = 3;
9          func();
10          return 0;
11      }
(gdb) p mainvar
$1 = 3
(gdb) c
Continuing.
In func()

Program exited normally.
(gdb) q

C>

---

Quote:

---

Originally Posted by vart

This is not a way to call a function in C. If you do not know this bit of info about C - why you still trying to answer any question here?

You just confusing people with such a crap.

---

I never implied it was a way to call a function hence the rest of your post is based up on
you initial false assumption and thus the 'crap' would appear to be a product of your own
mind.

The usual name used to refer to the region where global and static variables are stored is simply "the data segment." This is an area of memory distinct from both the stack and heap, where variables are loaded directly into memory from the program image.

"Uninitialized" global and static variables, or those which are initialized explicitly to zero, are often placed into yet a different segment called "BSS" which is not contained in the program image. This region is automatically zeroed by the runtime during program startup.

Quote:

---

Originally Posted by esbo

Well my point is basically that the question is a false one, he is not declaring a static
variable in this case, merely informing the compiler that the function returns an integer.

---

Quote:

---

Originally Posted by esbo

I never implied it was a way to call a function hence the rest of your post is based up on
you initial false assumption and thus the 'crap' would appear to be a product of your own
mind.

---

If we ask you another time, will we get another answer?

Quote:

---

Originally Posted by tabstop

If we ask you another time, will we get another answer?

---

Well you will get a reply, whether you get and answer depends to a large extent upon
whether your 'question' is comprehensible which unfortunately it is not on this occasion.
( obviously I mean comprehensibe to someone other than yourself).

It was comprehensible. First you mentioned "function," as in you were calling a function and it returned an int, and then you mentioned you never mentioned you were calling a function. That's what I gather.

Quote:

---

Originally Posted by dwks

They're called "auto" variables, after the keyword of the same name. Besides, you can see the value of automatic variables inside different functions if you need to, in the call stack. If you tried to see variables outside the call stack, you wouldn't get very meaningful values.

Code:

---

C>type viewvar.c
#include <stdio.h>

void func() {
    puts("In func()");
}

int main() {
    int mainvar = 3;
    func();
    return 0;
}

C>gdb -q viewvar.exe
(gdb) break viewvar.c:4
Breakpoint 1 at 0x401296: file viewvar.c, line 4.
(gdb) r
Starting program: viewvar.exe

Breakpoint 1, func () at viewvar.c:4
4          puts("In func()");
(gdb) bt
#0  func () at viewvar.c:4
#1  0x004012da in main () at viewvar.c:9
(gdb) frame 1
#1  0x004012da in main () at viewvar.c:9
9          func();
(gdb) l
4          puts("In func()");
5      }
6
7      int main() {
8          int mainvar = 3;
9          func();
10          return 0;
11      }
(gdb) p mainvar
$1 = 3
(gdb) c
Continuing.
In func()

Program exited normally.
(gdb) q

C>

---

---

I am not famiililar with that debugger as I don't use one at all myself but it seems you
that will only work on a few specific occasions and you cannot guarantee to be
able to see the 'variable'.

How do you know? I mean, you've never even touched a debugger, right? They're so filthy and complex and hate global variables that it gives you itches to use them, so you're better off with buggy code where you add a lot of printfs to track down your errors.

Quote:

---

Originally Posted by Elysia

It was comprehensible. First you mentioned "function," as in you were calling a function and it returned an int, and then you mentioned you never mentioned you were calling a function. That's what I gather.

---

No no have taken it out of context.

Quote:

---

I mean how could you access this static variable any way?

Code:

---


int somevariable;

somevariable=do_something;

---

---

I make no mention of calling the function here, so I am not sure where that idea came from.

Quote:

---

Originally Posted by Elysia

How do you know? I mean, you've never even touched a debugger, right? They're so filthy and complex and hate global variables that it gives you itches to use them, so you're better off with buggy code where you add a lot of printfs to track down your errors.

---

I can manage fine without a debugger, they tend to be counter productive, I don't tend
to get many bugs in my code so I have not have much experience using them unfortunately.

Maybe someone could explain how the deal with automatic variables?

Quote:

---

Maybe someone could explain how the deal with automatic variables?

---

Use them within an appropriate local scope.

I suggest that we let cs32 give a reply before we continue.

Elysia, kindly do not flame others.

Quote:

---

Originally Posted by laserlight

Use them within an appropriate local scope.

I suggest that we let cs32 give a reply before we continue.

Elysia, kindly do not flame others.

---

That suggests you can only see variables within scope, which is pretty much what
you would expect. However I guess you could write a debugger which would record
the values all variable even when out of scope if you wanted to. So it would depend
on the particular debugger, however I doubt many take that approach, if any.

Quote:

---

Originally Posted by esbo

However I guess you could write a debugger which would record
the values all variable even when out of scope if you wanted to. So it would depend
on the particular debugger, however I doubt many take that approach, if any.

---

What would be the reason for that?
Once they go out of scope, they disappear, so again, what is the point of recording those variables?
Variables that do not go out of scope is an entirely different thing.

Wow - a lot of activity in this thread. : )

My question was a purely abstract one. I was interested in knowing exactly what went on behind the scenes when a static variable was used in the context that I presented. The inspiration for my question came from the implementation of the strtok function. All of the answers (except those from esbo, which confused me to no end) were greatly beneficial.

Quote:

---

Originally Posted by brewbuck

The usual name used to refer to the region where global and static variables are stored is simply "the data segment." This is an area of memory distinct from both the stack and heap, where variables are loaded directly into memory from the program image.

"Uninitialized" global and static variables, or those which are initialized explicitly to zero, are often placed into yet a different segment called "BSS" which is not contained in the program image. This region is automatically zeroed by the runtime during program startup.

---

I've asked this question before, but I'll ask it again to see if I get different answers. How many different segments are there in a typical 32 bit program? It sounds like we have one for the stack/heap (what is this called, BTW? Is this the text segment?), one for global/static variables (data) and one for the compiled code. What else is there?

Thanks for the great answers.

I don't know if I would say the heap/stack is part of any segment.
Both reside the in the virtual memory, which is part of the physical memory. At least the heap is.

Quote:

---

Originally Posted by cs32

I've asked this question before, but I'll ask it again to see if I get different answers. How many different segments are there in a typical 32 bit program? It sounds like we have one for the stack/heap (what is this called, BTW? Is this the text segment?), one for global/static variables (data) and one for the compiled code. What else is there?

---

First, realize that 'segments' are a concept within the executable image, not necessarily in the memory of a running program. Typically there is a text segment which contains the executable code, a data segment which contains initialized data, and a bss segment which contains uninitialized data. The stack and heap are not segments, but are created when the program starts up.

Some linking formats, for instance ELF, allow you to define as many segments as you want, with whatever names you want. This is useful if you want to control the specific load addresses or VMAs of certain parts of the code. It is not something you would normally encounter. The ELF program header tells the loader how to load these segments into memory.

Once the program is running, the OS doesn't care about segments anymore. It's all just data and code sitting in memory at that point.

Quote:

---

Originally Posted by brewbuck

First, realize that 'segments' are a concept within the executable image, not necessarily in the memory of a running program. Typically there is a text segment which contains the executable code, a data segment which contains initialized data, and a bss segment which contains uninitialized data. The stack and heap are not segments, but are created when the program starts up.

Some linking formats, for instance ELF, allow you to define as many segments as you want, with whatever names you want. This is useful if you want to control the specific load addresses or VMAs of certain parts of the code. It is not something you would normally encounter. The ELF program header tells the loader how to load these segments into memory.

Once the program is running, the OS doesn't care about segments anymore. It's all just data and code sitting in memory at that point.

---

I agree with the above, however, the OS will "manage" three or four different sections of memory:
1. Code - this is normally non-writable. Sometimes called Text.
2. Data - May be non-executable. [1] Most variables are here.
3. Read Only Data - non-writable, may be non-executable. For example string constants are here.
4. Stack - Read-write, expands (towards address zero) as needed to a limit.

Any segment within the executable file will fall into one of the three first sections.

The heap is "read-write data", but (normally) not part of the executable, and expands according to the needs of the application. The OS may limit the amount of heap an application can use. The heap is managed as type 2 above, although with special OS calls, you can make heap segments executable for those apps that do "runtime code generation".

[1] Modern processors have a "No Execute" protection bit in the page-tables that manage the memory.

--
Mats

Quote:

---

Originally Posted by matsp

[1] Modern processors have a "No Execute" protection bit in the page-tables that manage the memory.

---

Speaking of page tables and memory protection, some processors (e.g. x86) also have a memory protection mechanism called "segmentation" which uses segments instead of pages for access control. This shouldn't be confused with the kind of "segments" we are talking about here, although the two things are not entirely unrelated.

Sometimes segments are referred to as "sections" instead.

Quote:

---

Originally Posted by Elysia

What would be the reason for that?
Once they go out of scope, they disappear, so again, what is the point of recording those variables?
Variables that do not go out of scope is an entirely different thing.

---

The might give an indication that a particular event has occured which might make it easier
to debug the program.

No, they are not global variables.
Variables that go out of scope are destroyed, so there's no no reason to keep their value around.
You obviously haven't used a debugger very much, so you wouldn't know.

Problems do not arise from a variable after it's destroyed.

Quote:

---

Originally Posted by Elysia

No, they are not global variables.
Variables that go out of scope are destroyed, so there's no no reason to keep their value around.
You obviously haven't used a debugger very much, so you wouldn't know.

Problems do not arise from a variable after it's destroyed.

---

1. I never said they were global variables.

2. Future states of a program may be dependant on previous states.

3 I have used a debugger but I can manage perfectly well without them,
futhermore a program may run in debug mode but crash when compilied normally.

4 Knowing the historical values of variables can be an aid to debugging a program.

Quote:

---

Originally Posted by esbo

4 Knowing the historical values of variables can be an aid to debugging a program.

---

Never mind the rest said i agree that 'coding style' is something as different among people as are nose shapes or eye colors, but for that line show a good example. I mean in the following code, what would it help if the value of the variables was known to track the bug?

Code:

---

unsigned int gory_mess(void *a, int size)
{
    int j;
    unsigned int hash;

    hash = 0xF348D6EE;
    for(j=0; j<size; j++)
        hash += (*(int *)(a + j + 1))<<(size - j);
    return hash;
}

---

Quote:

---

Originally Posted by xuftugulus

Never mind the rest said i agree that 'coding style' is something as different among people as are nose shapes or eye colors, but for that line show a good example. I mean in the following code, what would it help if the value of the variables was known to track the bug?

Code:

---

unsigned int gory_mess(void *a, int size)
{
    int j;
    unsigned int hash;

    hash = 0xF348D6EE;
    for(j=0; j<size; j++)
        hash += (*(int *)(a + j + 1))<<(size - j);
    return hash;
}

---

---

It might help you determine what is wrong with the program.

Quote:

---

Originally Posted by xuftugulus

I mean in the following code, what would it help if the value of the variables was known to track the bug?

---

It would make everyone write really simple code, because if the system had to take snapshots of the "function call stack" and the "stack frame" at each and every change of an automatic variable from program start to end, then if you wrote anything moderately complex you'd bog your system memory down with megabytes of useless information.
:p

[edit]Of course I'm merely having fun here. The system I'm on does provide me with a trace very much like this, but in a big circular buffer.

Quote:

---

Originally Posted by Dave_Sinkula

It would make everyone write really simple code, because if the system had to take snapshots of the "function call stack" and the "stack frame" at each and every change of an automatic variable from program start to end, then if you wrote anything moderately complex you'd bog your system memory down with megabytes of useless information.
:p

[edit]Of course I'm merely having fun here. The system I'm on does provide me with a trace very much like this, but in a big circular buffer.

---

This is probably why I don't use a debugger, it is easy to get bogged down in the detail,
it is usually better to step back and think about what is going on and often quicker, also
I have known programs which run fine when you compile in debug mode but crash when you
compile it normally!
I manage on a few debug printf statements, more thought, less data which is better than
megabytes of data but little thought about what might be wrong!

Quote:

---

Originally Posted by esbo

I manage on a few debug printf statements, more thought, less data which is better than
megabytes of data but little thought about what might be wrong!

---

This is a problem - you never wrote program bigger than several lines of code...

Quote:

---

Originally Posted by esbo

This is probably why I don't use a debugger, it is easy to get bogged down in the detail,
it is usually better to step back and think about what is going on and often quicker, also
I have known programs which run fine when you compile in debug mode but crash when you
compile it normally!
I manage on a few debug printf statements, more thought, less data which is better than
megabytes of data but little thought about what might be wrong!

---

Well, we've really strayed from the matter at hand thanks to esbo entirely. Somehow, now we're stuck discussing what you feel to be proper practice. We may as well discuss it somewhat seriously. Maybe we'll change your mind one of these days.

Quote:

---

Originally Posted by esbo

I have known programs which run fine when you compile in debug mode but crash when you compile it normally!

---

Quote:

---

I have written programs which run fine when you compile in debug mode but crash when you compile it normally!

---

Fixed! :p

On the whole I imagine that these programs are simply poorly written on your part. The whole purpose of debug mode is to find and fix problems; I can't imagine why it's okay to do it bass ackwards and expect that a release build makes it possible to encounter all the bugs you sneak in. I mean, I depend on my debugger to break execution when the program is about to crash. At least I likely know the area of the problem after that.

I'm not really against people stepping back and thinking, as you noted, but programmers who deserve to be employed already learn to do that. You're also endorsing a system of development that saps their productivity:

The whole notion that you can effectively debug a large project with printf's seems like a bit of a fallacy to me. I can't imagine working on even an open source project where volunteers were depending on printf to bump into errors. To track down a segmentation fault somewhere without the aid of another tool, for example, you would have to bloat your part of the code base considerably with printf calls and write sufficient wrappers for them so all those extra calls aren't compiled at all when you want to release. You probably won't agree with me here, but that seems like an excellent way to tack on kilos of useless information to your intermediate executables. Such a waste of effort! Because even after all of that you still have to hope that you made an appropriate guess at the problem area, then actually fix it.

I'm assuming one hell of a bug, but they happen to people and programmers quite indiscriminately. :D

This thread seems to have run its course.