Avoid potential integer overflow in Mmap.mmap

[kkretschmer]

There is a potential integer overflow in Mmap.mmap which can lead to an out-of-bounds access. The size of the memory-mapped array len is calculated as prod(dims). If this multiplication overflows, the allocated size will be too small and accesses towards the end of the array will fail with e.g. a segfault or other errors. I noticed this when using dims taken from a binary file header in UInt32 format. Using BigInt sizes will avoid this and will also allow the maximum size check below to work as intended.

[Seelengrab]

This check could be moved outside of the loop, since we only care whether any overflow occured at all. Very minor though, since length(dims) can have a maximum of 64 elements before it is guaranteed to overflow for UInt64, so probably wouldn't change much runtime wise and should be fine as is.

I think you meant to write prod($((sizeof(T), dims...))) (notice the extra pair of parentheses to signify the method call).

Other than that, LGTM!

[kkretschmer]

I had the check outside the loop at first, but this is not guaranteed to work. If the overflow does not occur on the last iteration of the loop, the last one may succeed and overflow == false at the end of the loop. Therefore I think that the check has to be done after every call to mul_with_overflow or overflow has to be accumulated using logical or.

I will push a fixed error message. It will then look like this:
ArgumentError: requested size prod((1, 9223372036854771710, 2)) too large, would overflow typeof(size(T)) == Int64

[Seelengrab]

I was thinking of unconditionally carrying the overflow with |= through the loop:

len = sizeof(T)
overflow = false
for l in dims
    len, of = Base.Checked.mul_with_overflow(...)
    overflow |= of
end
overflow && throw(...)

but as I said, I don't think it matters too much.

---

Yes, perfect - prod can't be splatted into after all, it takes collections.