MemoryMap does not fail the task if `munmap` fails

os.rs:

#[cfg(unix)]
impl Drop for MemoryMap {
    /// Unmap the mapping. Fails the task if `munmap` fails.
    fn drop(&mut self) {
        if self.len == 0 { /* workaround for dummy_stack */ return; }

        unsafe {
            // FIXME: what to do if this fails?
            let _ = libc::munmap(self.data as *c_void, self.len as libc::size_t);
        }
    }
}

Same for Windows. Crypto needs this guarantee to protect sensitive data.

[lilyball]

Does it really need this, or does it just need an explicit way to destroy the MemoryMap and return any error? I'm in favor of the latter. If you don't have security concerns, you don't want Drop to fail even if the munmap() does. If you do have security concerns, you can explicitly destroy the MemoryMap and handle any error as you see fit.

[thestinger]

If munmap fails, I think the process should abort, not fail. The only normal failure reason (as in not from something like seccomp) is EINVAL, which is a logic error and indicates that there's horrible memory unsafety going on.

[lilyball]

Reading the manpage, looks like @thestinger is right. munmap() failing signifies something serious is wrong.

[geraldstanje]

when will std::os::MemoryMap be stable?
i opened a new issue for those who used it before: #25538

[alexcrichton]

As @klutzy pointed out in #25538 this has since been removed, so I'm going to close this, but it's definitely something that needs to be considered if re-adding!

[alexcrichton]

@geraldstanje it's likely that this sort of functionality would start out as an external crate on crates.io before migrating into the standard library.