where are static values stored?

[cs32]

Given the following 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?

[whiteflags]

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:

#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?

[esbo]

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:

#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'
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 ).

[whiteflags]

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.

[esbo]

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?

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:-

int somevariable;

somevariable=(int)do_something;

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

[vart]

"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.

[whiteflags]

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++).

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.

[Elysia]

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'

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

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.

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.

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.

[matsp]

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

[dwks]

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.

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>

[esbo]

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.

[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.

[tabstop]

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.

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?

[esbo]

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).

[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.