-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Conversation
internal static partial class Sys | ||
{ | ||
[DllImport(Libraries.SystemNative, SetLastError = true)] | ||
internal static extern int MAdvise(IntPtr addr, size_t length, MemoryAdvice advice); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
bca10d3
to
a509f9e
Compare
|
||
shm_unlink(\"/corefx_configure_shm_open\"); | ||
|
||
// NOTE: PROT_EXEC, and MAP_PRIVATE don't work well ell with shm_open |
There was a problem hiding this comment.
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).
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. |
@stephentoub @socket anything else? I left my fixups as separate commits to see delta between iterations, but I'll squash them before merging. |
LGTM |
a509f9e
to
435d0e2
Compare
435d0e2
to
e001833
Compare
Shim memory map functions Commit migrated from dotnet/corefx@1c35165
System.IO.MemoryMappedFiles and System.Security.SecureString now have common Unix builds.
cc @sokket @stephentoub