Proposal: C# should provide better interop with unmanaged function pointers.

[tannergooding]

Ported from dotnet/roslyn#13240

Issue
C# has no mechanism for declaring unmanaged function pointers.

While there are a couple of mechanisms designed to work with and call unmanaged function pointers, these mechanisms may:

• Incur a higher level of overhead
• Require caching of the managed delegate
• Emit sub-optimal instructions for invoking the unmanaged function pointer
• Have issues when working with other unsafe/unmanaged code

Workaround
Declare the function pointer using IntPtr and then use the Marshal.GetDelegateForFunctionPointer method to convert to a managed Delegate. Such as:

[UnmanagedFunctionPointer(CallingConvention.StdCall)]
public delegate void _D();

public struct S
{
    private IntPtr pD;

    public void D()
    {
        var funcptr = Marshal.GetDelegateForFunctionPointer<_D>(pD);
        funcptr();
    }
}

public static class C
{
    [DllImport("SomeBinary.dll")]
    public static extern void CreateS(out S pS);
}

-or-

Declare a managed delegate and rely on the marshalling behavior to convert as appropriate. Such As:

[UnmanagedFunctionPointer(CallingConvention.StdCall)]
public delegate void _D();

public struct S
{
    [MarshalAs(UnmanagedType.FunctionPtr)]
    public _D D;
}

public static class C
{
    [DllImport("SomeBinary.dll")]
    public static extern void CreateS(out S pS);
}

Proposal
The C# language should be extended to support function pointers in an unsafe context. Such as:

unsafe public struct S
{
    public void (*D)();
}

The compilation should fail if unsafe is missing.

Advantages
The compiler could take advantage of the fact this is an unsafe function pointer and emit the calli instruction when invoking.

The compiler could provide some level of type safety when invoking the function pointer (ensuring the arguments passed in match the types required).

This would allow better interop with unmanaged languages and types that use function pointers.

This would allow a user to more readily implement VTBLs for unmanaged interop when required.

[tannergooding]

FYI. @jaredpar, who had some thoughts on how this could be implemented in a safe-manner.

[jaredpar]

The idea I had was for a more general purpose C# feature: static delegates.

static delegate int Func();

A static delegate differs from a normal delegate in the following ways:

1. It can only bind to static methods.
2. Under the hood it is represented as a struct that has a single member of type IntPtr. This means it has no heap allocation and can be marshaled using simple bit blitting.
3. It doesn't support operations like += and -= because it's not meant as a collection of callbacks, just a simple single callback.
4. Invocation is implemented using calli.

This adds a nice general purpose, light weight, call back capability to the C# language. This can be used in a variety of scenarios, including PInvoke. Attributes could be used on top of the declarations to support calling conventions very similar to the original proposal.

[tannergooding]

Under the hood it is represented as a struct that has a single member of type IntPtr. This means it has no heap allocation and can be marshaled using simple bit blitting.

Would a special attribute also be used to track the signature of the static delegate?

[jaredpar]

@tannergooding

The signature needs to be tracked in metadata. I wouldn't use an attribute though because that's generally a poor way of tracking certain kinds of types: generic type parameters for instance. Instead I'd prefer to generate a method on the struct that had the signature.

[tannergooding]

Makes sense 😄

[Korporal]

I like this suggestion. There are several areas where interaction with native environments is restrictive and this is definitely one.

[tannergooding]

@jaredpar, we talked about it a bit already, but would you be willing to champion this if I submit a formal proposal against the repo?

[jaredpar]

Yes. Need to buy a cape though. Feel weird being a champion without a better outfit.

[bbarry]

@jaredpar would that be usable even in safe code?

eg if I had:

static delegate int MyCallback(Handle h, int eventId);

[DllImport("SomeBinary.dll")]
public static extern void CreateCallback(out MyCallback pMyCallback);

[DllImport("SomeBinary.dll")]
public static extern void ReleaseCallback(MyCallback pMyCallback);

Would that be possible? Would that be allowed without /unsafe? Or could I use those from safe code?

usage (ignoring disposal impl best practices):

sealed class DoesSomething : IDisposable {
    MyCallback _callback;
    Handle _handle;
    
    public DoesSomething() {
        ExternUtil.CreateCallback(out _callback);
        _handle = ...;
    }
    public int Yo() => _callback(_handle, 1);
    public void Dispose() {
        _handle = ...;
        ReleaseCallback(_callback);
    }
}

[jaredpar]

@bbarry it would be allowed in safe code. It's just another delegate type that just also happens to be very usable in interop scenarios.

[tannergooding]

I opened an official proposal for this, taking into account @jaredpar's "safe" version 😄

[svick]

From the current version of the proposal:

The name of the struct should not be user-constructable (as we do with other internally generated backing structures).
For example: fixed size buffers generate a struct with a name in the format of <name>e__FixedBuffer (< and > are part of the identifier and make the identifier not constructable in C#, but still useable in IL).

I think the name should be exactly the same as what the source code contains. The user declared a type named Func, so metadata should contain a type named Func. I think that in every case where the compiler uses an unspeakable name, it's to refer to entities that should be hidden from the user. The struct generated for a fixed-size buffer is one example of this: the user declared a field called name, so the compiler generates a field named name and a type named <name>e__FixedBuffer (notice that it didn't change the name of the field).

This is important for reflection and for at least limited support of interop with languages that don't support the feature themselves.

Though maybe I'm missing something: @tannergooding, what is the reason why "Func isn't enough"?

The name of the method declaration should be a well known name used across all static delegate types (this allows the compiler to know the name to look for when determining the signature).

I think that name should be Invoke, to stay consistent with System.Delegate delegates.

[tannergooding]

I think the name should be exactly the same as what the source code contains. The user declared a type named Func, so metadata should contain a type named Func. I think that in every case where the compiler uses an unspeakable name, it's to refer to entities that should be hidden from the user. The struct generated for a fixed-size buffer is one example of this: the user declared a field called name, so the compiler generates a field named name and a type named e__FixedBuffer (notice that it didn't change the name of the field).

I think that is the point here, we generate a field called name and a backing structure would be called something like <name>e__StaticDelegate.

I think that name should be Invoke, to stay consistent with System.Delegate delegates.

This makes sense, provided we hook up the method to basically just be the calli instruction on the backing field.

[svick]

I think that is the point here, we generate a field called name and a backing structure would be called something like <name>e__StaticDelegate.

I'm confused, what field? I thought this proposal is about declaring a type, not a field.

To make it more concrete, consider this code:

static delegate void Func();


static void Nop() {}

void Call(Func f) => f();

void Main() => Call(Nop);

I think this should generate something like (hopefully my syntax for IL instructions not directly available in C# is obvious):

struct Func
{
    public IntPtr Function;

    public void Invoke();
}

static void Nop() {}

void Call(Func f) => calli f.Function;

void Main() => Call(new Func { Function = ldftn Nop });

There is no field called Func in the generated code. What am I missing?

---

I also noticed that the WellKnownCompilerName method is static. I think it should not be, so that it can be used by reflection and other languages to invoke the delegate, even if the common way would be to skip that step and directly calli the field.

[sunkin351]

I have one question... Suppose the static delegate value comes from native code... How would we verify that the value is valid? And by valid, I mean not null... Can we get a method for determining that?

[sunkin351]

Or, perhaps I should be asking if we could get a method to find out if the delegate is default or not.

[tannergooding]

This discussion is no longer needed as C# has shipped function pointer support.

[DeafMan1983]

What does external variable work? Like we missed Adobe Flash Player has also passing external variable like this:

[UnmanagedVariable]
public static sbyte *description;

Like in C++/C

extern const char *description;

Old AS3 - I know because I miss my past time with AS3:

// variable 
public var description:String;
...
   // pass external variable with MovieClip/Loader's Context
   var desc:String = swf_mc.desciption;

Do you think C# can access UnmanagedVariable from nativelibrary?

[sunkin351]

This is beyond the scope of this discussion. If you want something for this, I recommend creating an issue on this repository instead of commenting on an already resolved discussion.

[DeafMan1983]

Are you thinking about my suggestion? Do you want ignore my idea? Then I never help you. Thanks for skipping my idea now I will leave your development group. Thanks for nothing! I am very disappointed now.

[alexrp]

You are being told to create a separate discussion because that is the norm on this repository. No one said they want to ignore your idea.

[DeafMan1983]

Ok I will create new..