[userbinator]

It still works if the file doesn't fit in RAM

No it doesn't. If you have a file that's 2^36 bytes and your address space is only 2^32, it won't work.

On a related digression, I've seen so many cases of programs that could've handled infinitely long input in constant space instead implemented as some form of "read the whole input into memory", which unnecessarily puts a limit on the input length.

[dekhn]

Address space size and RAM are two different things.

[dataflow]

What they said is correct regardless of that though?

[conradludgate]

The point the article makes is that a 32GB file can be mmapped even if you only have 8GB of memory available - it wasn't talking about the address space. So the response is irrelevant even if technically correct

[lelanthran]

> What they said is correct regardless of that though?

I don't think so.

Their post is basically:

>> It still works if the file doesn't fit in RAM

> No it doesn't.

Which is incorrect: it actually does work for files that don't fit in RAM. It doesn't work only for files that don't fit in the address space, which is not what the author claimed.

[dekhn]

I'm pretty sure the parent post to mine was updated from "RAM" to "address space", although I'm not 100% sure.

[actionfromafar]

You can mmap with offset, for that case. Just FYI in anyone thought it was a hard limit.

[jiggawatts]

All memory map APIs support moveable “windows” or views into files that are much larger than either physical memory or the virtual address space.

I’ve seen otherwise competent developers use compile time flags to bypass memmap on 32-bit systems even though this always worked! I dealt with database engines in the 1990s that used memmap for files tens of gigabytes in size.