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.