Is converting a C++ method to a C function with a pointer argument an acceptable pattern?

Question

I use C++ on ESP-32. When registering a timer I have to do this:

timer_args.callback = reinterpret_cast<esp_timer_cb_t>(&SoundMixer::soundCallback);
timer_args.arg = this;

Here the timer calls soundCallback.

And the same thing when registering a task:

xTaskCreate(reinterpret_cast<TaskFunction_t>(&SoundProviderTask::taskProviderCode), "SProvTask", stackSize, this, 10, &taskHandle);

So the method is started in a separated task.

GCC always warns me about these conversions, but it works just as planned.

Is it acceptable in production code? Is there a better way to do this?

Answer 1

A reinterpret_cast is always fishy unless you know exactly what you are doing. Here, your code happens to work only due to GCC's calling convention for C++ methods, but this smells heavily like undefined behaviour. In particular you should not assume that member functions are in any way compatible with normal function pointers.

The usual approach would be to instead define a C-compatible function with the appropriate signature, which internally calls the C++ method. For example:

extern "C" static void my_timer_callback(void* arg) {
  static_cast<SoundMixer*>(arg)->soundCallback();
}

This cast is fine because we are casting back from a void* to the type of the pointed-to object.

Details:

• extern "C" specifies the language linkage of this function. Language linkage affects name mangling and the calling convention of the function. Member functions cannot have C language linkage. Language linkage is largely orthogonal to internal/external linkage.

• For a callback the function may be “private”, i.e. have internal linkage. The C code never refers to the callback by name. The above code snippet specifies internal linkage through the static keyword (not a static method!). Alternatively, the function could have been placed into an anonymous namespace.

  I am not entirely sure about the interactions between extern "C" and static (internal linkage). E.g. [dcl.link] says that “All function types, function names with external linkage, and variable names with external linkage have a language linkage.” I interpret this so that the type of my_timer_callback has C language linkage, but that its function name does not.

• A static_cast is appropriate here because we know the real type of the arg but cannot express it within the type system. In contrast a reinterpret_cast is appropriate when we want to reinterpret a bit pattern, e.g. a pointer to a numeric type.

• Functions are not ordinary objects, and member functions even less so. You may reinterpret-cast between function pointer types as long as the function is only invoked through its real type (and analogously for member function pointers). Whether you can cast function pointers to other types (e.g. object pointers or void pointers) is implementation-defined (background). On POSIX casts between function pointers and void* are allowed so that dlsym() can work. Other casts involving (member) function pointers are undefined. In particular, casts between member functions and function pointers are not possible.

Answer 2

Personally, the most compatible, easy to implement and easy to understand approach that I've found is to just provide a "wrapper" function, compatible with the expected C interface, which internally calls the method (and, in case it's not static, instantiate or use an existing instance to do that). It could be seen as a sort of a variation of the Adapter Design Pattern.