You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the Mmap wrappers for the Unix-derived OSes does not dispatch directly to the relevant syscall but relies on the mmapper layer. The mmapper adds address range validation and returns EINVAL for the ranges not matching the content of the mapping registry. While it might be arguably correct for most of the use cases, it also prevents partial Munmaps and similar valid parts of the pretty rich mmap semantics. I suggest that the existing implementation should be left as-is, but undisturbed access to the underlying OS primitives should also be provided. The scope of the extension would be minimal, as the low-level part already is there -- the package should just export more entry points. The naming details are irrelevant to me, so I leave them unspecified: I will be equally happy with MmapUnsafe as with MmapRaw.
The only suggestion I'd make is the return type: the functions should operate with uintptr, as their WinAPIVirtualAlloc() counterparts do. Wrapping the uintptr in a slice just to unwrap it in the follow-up step to recover the uintptr adds no value. I'll make the slice when I'm done.
The text was updated successfully, but these errors were encountered:
The current implementation of the
Mmap
wrappers for the Unix-derived OSes does not dispatch directly to the relevantsyscall
but relies on themmapper
layer. Themmapper
adds address range validation and returnsEINVAL
for the ranges not matching the content of the mapping registry. While it might be arguably correct for most of the use cases, it also prevents partialMunmaps
and similar valid parts of the pretty richmmap
semantics. I suggest that the existing implementation should be left as-is, but undisturbed access to the underlying OS primitives should also be provided. The scope of the extension would be minimal, as the low-level part already is there -- the package should just export more entry points. The naming details are irrelevant to me, so I leave them unspecified: I will be equally happy withMmapUnsafe
as withMmapRaw
.The only suggestion I'd make is the return type: the functions should operate with
uintptr
, as theirWinAPI
VirtualAlloc()
counterparts do. Wrapping theuintptr
in a slice just to unwrap it in the follow-up step to recover theuintptr
adds no value. I'll make the slice when I'm done.The text was updated successfully, but these errors were encountered: