Methods that take a function pointer can't be reflection invoked

[MichalStrehovsky]

This works in .NET 7 but throws in .NET 8.

unsafe class Program
{
    static void Main()
    {
        typeof(Program).GetMethod("Fnptr").Invoke(null, new object[] { IntPtr.Zero });
    }

    public static void Fnptr(delegate*<void> d) { }
}

I can't find a place in the design doc (#282) where this would be conscious choice. There's a discussion of a potential System.Reflection.FunctionPointer that would work similar to System.Reflection.Pointer but that is orthogonal - System.Reflection.Pointer and a boxed IntPtr/UIntPtr can be used interchangeably as far as reflection is concerned.

To add to the confusion, if the method returns a delegate*, we do allow reflection invoking it and the result will be a boxed IntPtr. Similarly, if the method takes a delegate* as an out parameter, we will box it as IntPtr.

There's a similar issue with FieldInfo.SetValue for a delegate*-typed field where we do allow IntPtr (but confusingly don't allow UIntPtr).

This inconsistency seems jarring.

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This works in .NET 7 but throws in .NET 8.

unsafe class Program
{
    static void Main()
    {
        typeof(Program).GetMethod("Fnptr").Invoke(null, new object[] { IntPtr.Zero });
    }

    public static void Fnptr(delegate*<void> d) { }
}

I can't find a place in the design doc (#282) where this would be conscious choice. There's a discussion of a potential System.Reflection.FunctionPointer that would work similar to System.Reflection.Pointer but that is orthogonal - System.Reflection.Pointer and a boxed IntPtr/UIntPtr can be used interchangeably as far as reflection is concerned.

To add to the confusion, if the method returns a delegate*, we do allow reflection invoking it and the result will be a boxed IntPtr. Similarly, if the method takes a delegate* as an out parameter, we will box it as IntPtr.

There's a similar issue with FieldInfo.SetValue for a delegate*-typed field where we do allow IntPtr (but confusingly don't allow UIntPtr).

This inconsistency seems jarring.

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-System.Reflection
Milestone:	-

[MichalStrehovsky]

A thing this also implies is that introducing System.Reflection.FunctionPointer will likely necessitate a breaking change if we want to be consistent with normal pointers - the places in reflection that return pointers return a S.R.Pointer, not a boxed IntPtr. We currently return a boxed IntPtr.

So the question is also whether we want to be done with function pointer breaking changes in .NET 8, or postpone this one further. .NET 8 feels like a good opportunity since we're making a breaking change around this anyway.

[steveharter]

and a boxed IntPtr/UIntPtr can be used interchangeably as far as reflection is concerned.

FWIW in v7 CoreCLR, only IntPtr can be used (for function pointers) but yes going forward both should be supported.

[steveharter]

To add to the confusion, if the method returns a delegate*, we do allow reflection invoking it and the result will be a boxed IntPtr. Similarly, if the method takes a delegate* as an out parameter, we will box it as IntPtr.

A thing this also implies is that introducing System.Reflection.FunctionPointer will likely necessitate a breaking change if we want to be consistent with normal pointers - the places in reflection that return pointers return a S.R.Pointer, not a boxed IntPtr. We currently return a boxed IntPtr.

The lack of support for System.Pointer was called out in the design: https://github.com/dotnet/designs/pull/282/files#diff-aa1be871163360183955101af051dd78199829d1cdb52d20b398651bd3240d88R503

Although supporting Pointer (which is a reference type) would be consistent, it also introduces a potential perf for any future case where we don't require boxing -- so a System.FunctionPointer value type would be better, but overkill IMO.

[steveharter]

Closing as fixed from #90270.

We could create a v9 issue to support System.Pointer or some other mechanism for a function pointer return value based on feedback \ priority.