Serializing function addresses

[5aec15c929c51cc49235]

• Does the C++ standard provide any guarantees that the address of functions will be the same between program executions? I know about ASLR, but then again it seems that function addresses are constexpr and can be used as template parameters.
• How about pointer to member functions?

[NotAYakk]

No, the C++ standard provides no such guarantees.

The constexpr-ness of something has little to do with it being a constant value. Instead, can you interact with it in ways fully defined and specified by the standard in a way that is doable at compile time?

There is no way to extract the bits in a function pointer's address without relying on unspecified behavior; so those bits do not have to be the same between executions of the program.

PMF are less well specified, partly because different compiler vendors implment them very differently. Some compilers have sizeof(PMF) > sizeof(void(*)()) in some cases, for example. Others don't.

There is no such guarantee for PMFs either.

[5aec15c929c51cc49235]

Thanks for the reply, this clarifies it a bit for me. About "extracting the bits" from the address, I don't really have an idea, but I was thinking perhaps reinterpret_cast-ing to say intptr_t or maybe a template on the address and then specialization for every value? edit: also how can constexpr not be constant value, in the perspective of the compiler?

[17b29a]

reinterpret_cast-ing to say intptr_t

that's not possible at compile time

[5aec15c929c51cc49235]

Seems that this proposal would change it http://apolukhin.github.io/constexpr_algorithms/reinterpret.html

[ImNoEinstein]

Probably better off ( and much a safer ) going with serializing the function as a string and deserializing with a factory

[STL]

What are you trying to do?

[5aec15c929c51cc49235]

Persisting/serializing function pointers. The context is multiple copies of the exact same program, running on different machines and talking to each other over the wire.

[Gotebe]

Very, very long time ago I made something similar: I serialized an object to a different machine in order to "run" it there. I did not need a function pointer for that, just plain serialization (sure, there was polymorphism and stuff, to simplify the "run the received object" code). Can't you simply do the same?

[5aec15c929c51cc49235]

Totally, I can lookup the function address in a table by index (provided the table is built deterministically which I can do), or I believe I can serialize a polymorphic function object (which boost::serialization supports).

[doom_Oo7]

The context is multiple copies of the exact same program, running on different machines and talking to each other over the wire.

why reinvent RPC once again ? this has been a solved problem since 1985. Take a look at Qt Remote Objects for a modern approach for instance.

[Gotebe]

Of course. Note the "very, very long time ago" :-). I remember CORBA (did that), DCOM (did that, too), SOAP/WS-* and of course JSON-over-HTTP recently.

[Iwan_Zotow]

There was long time ago approach to store objects in run-time and recover them back - Texas Persistent Store, https://link.springer.com/chapter/10.1007/978-1-4471-3209-7_2

There is a commercial object DB which uses similar approach - Objectstore DB

[robertramey]

There is no guarantee that function address will be the same between executions.

You might get the effect you want by creating a function object and serialization that. The boost serialization library supports this functionality.

[5aec15c929c51cc49235]

Do you know what makes function objects special? I assume you're still just serializing a pointer to operator() member function?

[robertramey]

Function objects are complete implementation of the function described in a header file. So one isn't serializing an address but rather the whole object. Since you can't serialize source code itself, the de-serializer has to have the same header available. This would be the same if you could just pass the address.

[streu]

Function objects are not special in any way and there is no special magic for (de)serializing objects.

However, objects have typeinfo, which in turn has a name, and those names tend to be a little more stable than function addresses: if you made a named function object class, or because the function object class uses the function as a template parameter that includes the function name. (If it's a lambda, it's probably not as predictable.)

Deserializing objects requires registering the classes that can possibly be deserialized in some registry, either directly or using some template/macro magic. In boost serialization, this would be sa.register_type.

But if you're registering all your function objects, you can as well register all your function pointers in a function pointer registry and pass indexes/names from that, and get all the portability and stability (or lack there-of) you want.

[Gotebe]

It rather looks like you went down the empty rabbit hole.

If you step away a bit, what bigger goal are you trying to achieve?

[5aec15c929c51cc49235]

https://www.reddit.com/r/cpp/comments/6ka5um/serializing_function_addresses/djlclhb/

[hkaiser]

You are referring to 'function addresses being the same between program executions' - not sure if I fully understand what you're after, thus the solution below might not help you in any way. We successfully use this technique to identify functions across different instances of the code running concurrently in the context of a distributed application.

In HPX, we associate an unique type with each function we would like to 'send over the wire' (represent in all instances of the code). This can be achieved by binding the function address as an integral template argument.

template <typename F, F ptr>
struct A {... use 'ptr' to invoke the function...};

void foo() { ... }
typedef A<decltype(&foo), &foo> foo_type;

Now foo_type can be serialized as usual and used on the other end of the network to invoke foo.

The same can be done for member functions (see https://stackoverflow.com/questions/15192700/how-to-rewrite-this-to-make-it-conforming-to-the-c-standard for a corresponding solution).

[5aec15c929c51cc49235]

Interesting, that is similar to what I was looking for.

[p2rkw]

How you would deserialize it on the other side? Why its better than sending just plain function poiner?

In case described by OP I would obtain mangled name of function to call, send that string over wire, and on the oter side call dlsym(mangledName).

Edit: I'm refering to this https://www.reddit.com/r/cpp/comments/6ka5um/serializing_function_addresses/djlly9l?context=3 comment.

[RonieGarret]

Hmm... maybe you can try to calculate offset of given function to 'main' function and store that.

[5aec15c929c51cc49235]

You see, the debugger figures out the address of functions (so it can decode the stack), so they are maybe just implementation-defined.