Yes, that should work, as long as you make sure to ensure it gets zero terminated so you don't have to do length checks all over the place - that'd lose a lot of the benefit. For files that are not a multiple of the page sizze that's guaranteed. I've never tried to request mapping of more bytes than a file takes, though... I'm going to guess that still does something sane, but I've not tested it.
> I've never tried to request mapping of more bytes than a file takes, though... I'm going to guess that still does something sane, but I've not tested it.
Sadly, the Opengroup and Linux man pages say that
> Memory access within the mapping but beyond the current end of the underlying objects may result in SIGBUS signals being sent to the process.
Joy... Oh, well, I think on modern systems it'd be reasonable to just refuse to deal with source files that are too large to load into RAM, and leave it at that.
Wait, are you saying that one can't mmap a file larger than physical memory. Isn't this exactly what mmap is for. I think what masklinn is saying if you mmap a file, you can't read past the end or over allocate a single mapping. One could have another output mmap region.
It doesn't reliably do something sane. IIRC, LLVM in that case just falls back to reading the file into an array the ordinary way. That only happens one time in 4096, so there's no practical difference to performance.
