`map_anon()` can unsoundly create overlarge slices in safe code about memmap2-rs

[RazrFalcon]

I guess you're referring to:

However, some 32-bit and 16-bit platforms may successfully serve a request for more than isize::MAX bytes with things like Physical Address Extension. As such, memory acquired directly from allocators or memory mapped files may be too large to handle with this function.

An assertions would be too sporadic. I guess we should simply return an error and update the docs.

[RazrFalcon]

I cannot find how std::fs::read handles this. It should have the exact issue.

[RazrFalcon]

@adamreichold Hi! Can you comment on this one? It fills like half of the bugs we had are 32-bit related. But disabling its support completely would be too much.

[LegionMammal978]

I cannot find how std::fs::read handles this. It should have the exact issue.

Following the call chain, std::fs::read()

1. calls <File as Read>::read_to_end(),
2. which calls Vec::<u8>::reserve(),
3. which calls RawVec::<u8>::reserve(),
4. which calls RawVec::reserve::do_reserve_and_handle::<u8, Global>(),
5. which calls RawVec::<u8>::grow_amortized(),
6. which calls alloc::raw_vec::finish_grow::<Global>(),
7. which calls alloc::raw_vec::alloc_guard(),
8. which checks the size in bytes against isize::MAX as usize.

Even if it fails to get the file size, it

1. calls std::io::default_read_to_end(),
2. which repeatedly calls Vec::<u8>::extend_from_slice(),
3. which calls <Vec<u8> as SpecExtend<&u8, slice::Iter<'_, u8>>::spec_extend(),
4. which calls Vec::<u8>::append_elements(),
5. which calls Vec::<u8>::reserve(),
6. which checks the size as before.

[RazrFalcon]

Nice find! I guess I will borrow this function.

[adamreichold]

@adamreichold Hi! Can you comment on this one? It fills like half of the bugs we had are 32-bit related. But disabling its support completely would be too much.

I think it is a straight-forward error on our side. We do have the necessary check for file-based mappings in MmapOptions::get_len, but not in MmapOptions::len.

[adamreichold]

I think our check in get_len was actually too lenient as well. I still think this is a straight-forward bug though, as exposing mmap (2), we are in the memory allocator business need to take the same care as other implementors of such functionality. 😓