Skip to content
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

Keep blittable layout class In/Out by default #50655

Merged
merged 2 commits into from
Apr 2, 2021

Conversation

elinor-fung
Copy link
Member

// If neither IN nor OUT are true, this signals the URT to use the default
// rules.
if (!m_in && !m_out)
if (alwaysInOut)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should only be for non-byref cases.

@elinor-fung
Copy link
Member Author

Bah, it looks like we have a bug and test gap with handling null.

Before this and #50137, passing null to this p/invoke worked:

[StructLayout(LayoutKind.Sequential)]
internal class TestClass
{
    public int i;
}

[DllImport("NativeLib", CallingConvention = CallingConvention.Cdecl)]
public static extern void update_test_class([In][Out] TestClass c);

Now, it fails with a null ref exception trying to call Object.GetType(). With #50137 but without this change, it would only fail if [Out] is specified. With this change, it fails without [Out] since this change made that the default.

Anipik pushed a commit that referenced this pull request Apr 6, 2021
…ly marshalling the type if it doesn't match the static type in the signature. (#50138)

* When marshalling a layout class, fall-back to dynamically marshalling the type if it doesn't match the static type in the signature.

* Allocate the correct amount of space for the native data based on the runtime type.

* Apply suggestions from code review

* Keep blittable layout class In/Out by default (#50655)

* Do the exact type check after the null check.

Co-authored-by: Elinor Fung <[email protected]>
@ghost ghost locked as resolved and limited conversation to collaborators May 3, 2021
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[6.0.100-preview.4.21178.2] Package LibGit2Sharp not working with 6.0.100-preview.4.21178.2
4 participants