Forgive me if this sounds like a newbie question. Any time you obtain a virtual stack address from a pointer, such as doing something like:
printf("%d\n", &var);
what is this address relative to by default? Is it the stack segment, the extra segment, what? Is there a way to obtain the complete physical address? Thanks
It depends how you create the variable...
Code:char z[150]; // will be in the program's data segment int SomeFunc(voic) { char s[150]; // will be on the stack char* s = malloc[150]; / /will be a pointer on the stack, directing you to the heap. }
You're talking in terms that might have been current in 1993...Originally Posted by stevenswj
It's not relative to any segment. It's just a virtual address. On an x86 processor, it's technically relative to SS but on all modern operating systems the segmentation system isn't used anyway, so the particular default segment is irrelevant.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Btw, you are printing addresses with %p, right? And casting them to void* first?
As noted before, it depends on whether the variable has been defined (inside) outside of any function.
And what's the "extra" segment? Program's are divided into 3 segments/sections - text, data, and stack.
Not unless you're working on a system w/o an OS or an OS w/o the address translation functionality built into it.
And if that's the case, the printf() output is indeed the physical address else you're looking at the virtual address.
It doesn't matter. It's still just a virtual address, relative to nothing. Or to 0, if you will.
IBTD, it matters when trying to program a microcontroller w/o an OS, as data values can be installed at absolute memory addresses.
We are not discussing non-OS here. All the information provides thus far is with regards to a modern operating system with virtual memory addressing. In which case, it doesn't matter.
If you strip away that, then there are simply no rules regarding what is relative to where or how.
Elysia... Going back to the answer I gave our friend.
The first example --what might be called a Global variable-- actually occupies space in the program image itself. Usually the compiler groups them together in a "data segment".
The second example is created on the program's stack at run time as the procedure is entered. This is not part of the program's image, but does occupy space on the stack.
The third example using Malloc creates two bits of memory... the first on the stack (because the pointer is inside a procedure) and the second in the shared memory heap.
This I know from experience in windows shell... I had a small program with a large array; about 1050 long ints. At first I was just making it global but a kind soul on another forum suggested that I should probably use malloc... my program size immediately dropped by 4k... Which was significant in a program that was only 16k to begin with.
So, yes, it does matter.
Not so sure about that unless the op sheds more light on what s/he is doing.
If you strip away all that, then there are no "relative" rules, just "absolute".
The only reason why program size dropped by 4k is because storage for malloc() is allocated at runtime, instead of at compile time.
Yes, I know that. In fact that was my point... If you're going to create large blocks of memory use malloc instead of producing a monster program that's mostly empty space.
But an un-initialized global array, no matter how big, won't consume any space in the program.
Aren't static variables initialized to 0 implicitly?
In C, nothing is implicitly initialized.
If you want "int A = 0;" you have to say so.
