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'.
Printable View
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.
Use them within an appropriate local scope.Quote:
Maybe someone could explain how the deal with automatic variables?
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.
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.
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
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.
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.