Re: FileName or &FileName
FileName is what I prefer to &Filename, unless I want to stress that I am taking the address of the first element of an array (like if I'm doing something one element at a time). However, it's really just a matter of preference. The compiler will likely optimize it out to the same thing.
Re: Are pointers stored in memory?
Pointers are stored in memory just like any other variable. Your FileName variable takes up sizeof(void*) bytes for the memory location of the additional 512*sizeof(wchar_t) bytes for the array.
The reason is because you might want to do FileName = otherLocation and change where it is located. This is done more with dynamically allocated memory (malloc and free).
Re: Why didn't it fail?
Since pointers are stored in memory, when you took the address of FileName, you were given a valid pointer. C++ does the type-checking, but with your cast, it says, "hey, they're both pointers, so why not?"
GetModuleFileNameW(0,(LPWSTR) &Filename,0x200); will write the EXE file name into the memory at &FileName (not where you want, but hey, it's still writable memory).
WriteConsoleW(stdout, &Filename, l, &trash, 0); expects a void*, and wchar_t** can be cast to void* implicitely, so this one doesn't stop the compiler. WriteConsoleW here will output the actual file name returned by GetModuleFileNameW because they are both using the erroneous memory address, &FileName.
I expect that the other WriteConsoleW functions don't work, though. Do they?
P.S. Since GetModuleFileNameW will be writing to memory that holds who-knows-what (definitely variables for your program, though), then it may end up overwriting other bits of data and cause bugs in other parts of your program. These are terribly difficult to debug unfortunately... It works here, but it might cause problems elsewhere (and the bug might change each time since the OS may arrange your data differently each time you run the program).
Constant numbers for pointers in EXE
We're moving further away from what I know, but I'll give this my best shot.
The OS gives your application its memory, so your program can't just do something like printf( 0x56FA3FB0, 0x56FA3FF9); because those numbers will likely change every time your EXE is run.
One thing that your application can do, though, is store offsets to constant (non-writable) pieces of memory. For example, const char * str = "Hi, Wo"; might be stored at offset 0xCD3F in your EXE. When it's loaded, just move from where the EXE is in memory forwards 0xCD3F bytes to get to the beginning of the string, "Hi, Wo".
Non-constant pieces of data can't be stored as offsets, though. With constant data, you can put stuff with the EXE code, but for non-constant (read-write) data, you have to ask the OS for such memory, and you can't predict where the memory will be located. For example, with const str2; strcpy(str2, str);, the OS will be asked for seven bytes, then the data from str (which is in the EXE code which is in read-only memory) can be copied over to the memory that the OS gave you for str2.
That is my basic understanding of how this works. I know there's more, like giving the OS a hint for how much data you'll use and stuff like that. shrugs At least, this is the info I've collected over the year, and hopefully it's right and can provide yet more insight into pointers and memory.
Return to Index
|Response Title||Author and Date|
|Re: Interesting.||Michael Calkins on Sep 15|
|Re: Interesting||ComputerGhost on Sep 15|
|Re: Interesting||Michael Calkins on Sep 16|
|* const data goes in .rdata, not .text||Michael Calkins on Aug 22|