C# GetFunctionPointerForDelegate cdecl instead of stdcall

Question

I'm trying to work with a (C) third party library that has a callback mechanism that lacks any possible way of identifying the calling context. My main project is in C#, and my wrapper is a C++/CLI project to call the C library APIs.

To work around this problem, I'm attempting to use Marshal::GetFUnctionPointerForDelegate. Here is my C# code:

void Init(Handler Callback)
{
    // Create a wrapper lambda in case Callback is a non-static method.
    instance.CreateBuffers((x, y) => Callback(x, y));
}

Then, in the C++/CLI code:

void CreateBuffers(Handler^ Callback)
{
    pinCallback = GCHandle::Alloc(Callback);

    void (*callback)(int, int) = (void (__stdcall *)(int, int))Marshal::GetFunctionPointerForDelegate(Callback).ToPointer(),
    // Use 'callback' in third party library...
}

The problem with all this is that according to http://msdn.microsoft.com/en-us/library/367eeye0.aspx, the function pointer from Marshal::GetFunctionPointerForDelegate is an stdcall function, but my C callback is cdecl. How can I get a cdecl compatible function here?

Answer 1

I think that the simpest way to achieve this is to declare your delegate type is C# with the UnmanagedFunctionPointer attribute to specify the calling convention.

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate ...

Then make your C++/CLI code receive a plain native C++ function pointer. You can pass an instance of your delegate, and because the delegate has that attribute, the marshaller knows what to do.

This allows you to skip the GetFunctionPointerForDelegate step. In fact it would allow you to skip right over the C++/CLI layer, but I expect that you don't want to do that.

Make sure that your managed code retains a reference to the delegate for as long as the unmanaged code can see the function pointer. If you don't do so then the garbage collector may pull the rug from under you since it cannot see the reference held by the unmanaged code.

This topic has been covered here before, of course. Hans Passant has a detailed answer here that is worth reading: Correct way to call a C DLL method from C#