-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider supporting varargs calling conv in function pointers to unblock interop scenarios #3718
Comments
mean to put this in the lang repo thanks fred 🙂 |
Just a brief note. (I like to think of |
See also discussions here: dotnet/runtime#82081 Currently this blocks us from supporting linux for a single library that has varargs. |
This prevents us from interoping with code that expects caller to make some kind of Currently it is done like this: [UnmanagedCallersOnly]
[SkipLocalsInit]
static void LogEntryPoint(void* avcl, int level, byte* fmt, void* varargs)
{
// Some code requiring manual varargs parsing...
}
delegate* unmanaged<void*, int, byte*, void*, void> callback = &LogEntryPoint;
av_log_set_callback(callback); I personally would prefer having delegate* unmanaged<void*, int, byte*, __arglist, void> Or maybe just use delegate* unmanaged<void*, int, byte*, ArgIterator, void> |
Currently, function pointers don't support the
vararg
calling convention (analogous to a final param of__arglist
in a normal method), which blocks any native interop in scenarios you need to dynamically load pointers to vararg functions (such as invoking the python API where are large proportion of methods are varargs, or in objective-C interop for Metal).I could see 3 possible syntaxes for this - explicit
__arglist
,varargs
specifier, or bothInvocation sytnax could then be implicit or explicit, again
I think this is a reasonable request as there is effectively no workaround for this without language support and so it is a pretty unfixable blocker for some of these scenarios
The runtime support is already there, as far as I know (on windows).
The text was updated successfully, but these errors were encountered: