Then I think you need to really ditch the virtual memory attachment if you want to really nail the basics.
Printable View
Then I think you need to really ditch the virtual memory attachment if you want to really nail the basics.
i have been thinking about the subtleties in this and i made this little test project that i think helped me understand the differences here
stepping through the code with the debugger shows that a0 in main is equal to a in the body of func.Code:void __fastcall func(char *a[])
{
}
int main()
{
char *a[4]={"s0","s1","s2","s3"};
char **a0 = &a[0];
func(a);
return 0;
}
hope that is similarly somewhat useful to someone else.
Perhaps, but I doubt it. The issue here is one of syntax and language semantics, which are lost i the low-level execution.Quote:
hope that is similarly somewhat useful to someone else.
On a side note, never asign string literals to char*. Always use const char*.
Not at all. Virtual memory is a mechanism for operating system to separate processes from each other and allows paging and stuff like that. It's completely irrelevant to the application's usage of pointers.
But it does explain why you get a crash when you access a non-modifiable page and the concept of addresses.
Virtual memory is the basics of more complicated OS memory management, not pointers. You could easily use pointers on a system that doesn't have virtual memory.
edit: beaten
no it doesn't. it could be implemented with simple range checking.
Because it makes sense to me. You access a page you don't have access to, you get a crash. Simple. That's how modern OSes works.
Whatever. What point is it to argue?
Knowing VM makes it easier to understand pointers to me. Let it be that way.