Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

Shim memory map functions #3143

Merged
merged 3 commits into from
Sep 11, 2015
Merged

Shim memory map functions #3143

merged 3 commits into from
Sep 11, 2015

Conversation

nguerrera
Copy link
Contributor

System.IO.MemoryMappedFiles and System.Security.SecureString now have common Unix builds.

cc @sokket @stephentoub

internal static partial class Sys
{
[DllImport(Libraries.SystemNative, SetLastError = true)]
internal static extern int MAdvise(IntPtr addr, size_t length, MemoryAdvice advice);
Copy link
Member

Choose a reason for hiding this comment

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

If we've decided to use uintptr_t / UIntPtr for size_t, can we just do so in our signatures on both the managed and native sides and not do the "using size_t = System.UIntPtr;" thing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm still a bit torn on my size_t approach and considering going to ulong/uint64_t everywhere.

Right now, it's actually declared as size_t in the native code and not uintptr_t, but there's a static assert to check that size_t is what we expect.

UIntPtr on managed side is a pain (no arithmetic, comparison operators, etc.) On native side, if we used uint64_t, we'd have to do a few < SIZE_MAX checks (or have debt to do so when x86 comes online), but it would make the managed code easier to maintain I think.

I guess there are the following options:

(a) Managed=UIntPtr, Native=size_t, static assert that sizeof(size_t) == sizeof(uintptr_t)
(b) Managed=UIntPtr, Native=uintptr_t, static assert that sizeof(size_t) == sizeof(uintptr_t)
(c) Managed=ulong/Native=uint64_t, native fails calls if it sees size > SIZE_MAX

(a) is what I have now, but (c) is where I'm leaning.

What do you think?

Copy link

Choose a reason for hiding this comment

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

I agree with (c)...I've been converting size_t (and other types like it) to long types; it seems much cleaner to me and makes an easy contract.

Copy link
Member

Choose a reason for hiding this comment

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

I like (c) best as well, followed by (b). I'd prefer not (a).


shm_unlink(\"/corefx_configure_shm_open\");

// NOTE: PROT_EXEC, and MAP_PRIVATE don't work well ell with shm_open
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I couldn't repro the ftruncate failure on OS X, but I left the refactoring I did to make it easier to add more checks.

Also, self nit: 'work well with' (will fix before squashing).

@nguerrera
Copy link
Contributor Author

I switched everything to ulong/uint64_t, but haven't added any range checks yet. This means things can technically overflow on 32-bit, but generally the managed code is passing in things that fit in uint.MaxValue or else checking IntPtr.Size before using them regardless. Still we should be more careful. I filed #3165 to make sure we catch narrowing implicit conversions and I'll build things on x86 with that on when I fix it to add appropriate range checks.

@nguerrera
Copy link
Contributor Author

@stephentoub @socket anything else? I left my fixups as separate commits to see delta between iterations, but I'll squash them before merging.

@stephentoub
Copy link
Member

LGTM

nguerrera added a commit that referenced this pull request Sep 11, 2015
@nguerrera nguerrera merged commit 1c35165 into dotnet:master Sep 11, 2015
@nguerrera nguerrera deleted the shim-work branch September 11, 2015 02:10
@karelz karelz modified the milestone: 1.0.0-rtm Dec 3, 2016
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants