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.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.
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.
Thanks for the great answers.
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.
1. Code - this is normally non-writable. Sometimes called Text.
2. Data - May be non-executable.  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".
 Modern processors have a "No Execute" protection bit in the page-tables that manage the memory.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
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.
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.