-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fail nicely for non-blittable function pointer signatures #40908
Comments
Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar, @agocke |
Unmanaged function pointers do support non-blittable arguments for backward compatibility. Unmanaged function pointers have existed in IL since .NET Framework 1.0. They have been used extensively by managed C++ and other non-C# code generators. Changing the runtime to throw on unmanaged function pointers with non-blittable argument would be significant breaking change. The standard marshaling rules apply for calling unmanaged function pointers with non-blittable arguments. The example that was crashing for you would work just fine if the unmanaged method returned allocated string (it is the standard marshaling rule for Maybe this can be an analyzer? |
With the I think this covers the scenario enough and that we don't need an analyzer. |
Overview
Today I spent too long debugging an error code of
-1073740940
only to find that my source generator wasn't manually marshalling string returns for function pointers like it's supposed to. This is fine because (eventually) I got to where I was going wrong, however the manor in which is failed was less than desirable.Actual Suggestion
To ensure noone experiences something like tonight's traumatic debugging experience again, I'd like to suggest that upon calling a function pointer, throw a managed exception if any of the parameters or return value is non-blittable such that proceeding with the call will result in a runtime failure, rather than continuing to a critical error.
Extra Information
Here's some information on what led me to make this suggestion and how the runtime currently deals with a failure of this sort.
Function pointer signature:
delegate* cdecl<string>
WinDbg stack trace:
CLR stack
The text was updated successfully, but these errors were encountered: