Thread: where are static values stored?

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

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.