For example, if I declare a function in the main application, and a pass a pointer to it, from a dynamically loaded library (via dlopen
under Linux or LoadLibrary
under Windows) using a gotten symbol argument (via dlsym
or GetProcAddress
respectively) and try to call that function, would it work properly?
Same if pass pointer from one dynamically loaded library to another? I think it should work if pointer at least relative to application but not relative to module/library.
Another example. I declare a function in one application and pass pointer to it to another fully-independent application (both C and C++) somehow (parameter string or file i/o - idk how, just an idea) and try to call this function, would it work too? I could expect it to work if the pointers are absolute. Maybe it just won't work because system won't like such cross-call at all because of safety?
First you must understand that in C and C++ the value of a pointer is not required to be related to the addresses actually used, as long as pointer arithmetic works with it, the null pointer has an R value of 0 and the implementation manages to bijectively map between machine pointers and language abstract pointers.
On modern systems processes see a virtual address space and each process has its own address space. Libraries may be loaded to any address, thus passing a pointer between processes is utter nonsense – at least on paged memory architectures. However within a process machine level pointers are passed between loaded libraries with no problem; after all they share the same address space. On the language level they may not be the same (though usually the are), if multiple languages get into contact. But compilation units created using the same compiler will use the same pointer semantics. Also most language implementations that target the native machine agree on the pointer semantics for the simple reason, that having to convert between pointer formats would create a huge performance hit.
It's absolute.
The fact that it's a virtual address has nothing to do with this -- it's an absolute virtual address. It makes no difference to your program whether it's using virtual memory or physical memory... you shouldn't concern yourself with this unless you're passing pointers between processes (which I seriously doubt you are), or unless you're writing low-level kernel code or mapping/unmapping pages manually (which I also doubt you are).
Things work differently on different operating systems. On older / embedded operating systems all processes share the same space - one process can easily mess things for another.
On most general-purpose (i.e. not embedded) modern operating systems each process has a separate address space. All addresses are relative to this space. It doesn't matter how things are compiled / linked together, if they're in the same process, they share the address space.
It follows that two distinct processes have no implicit ways of accessing each-others space.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With