Robert, et al., thanks very much. possibly mh-e could add something like a comma before integers. i'll ask and look.
on the more general issue, you all know a lot more about all of this than me. but ... :) while actual bytes of memory on my laptop are semi-precious, addresses in the address space are much less so. here's somebody who uses mmap(2) to allocate a huge chunk of address space, and then madvise(2) (a call i think i've never used) to have that chunk backed by (lots and lots of) zeroes. ---- https://robert.ocallahan.org/2016/06/managing-vast-sparse-memory-on-linux.html ---- i get the sense that nmh will only (after maybe zeroing the array, which would be eliminated in this scenario!) access locations in the array corresponding to actual "messages" found in the directory. so, this sparse array should stay sparse, right? this wouldn't solve all problems -- places where the difference between the largest and smallest "message" numbers is greater than the size of the address space (+/-). but, i wonder if it might help. maybe combined with those places where d_type is supported (and not "unknown") in directory entries. at least as a temporary fix? and, if the mmap(2) call fails, that's maybe a way to provide a more graceful termination than lots of sluggishness, then OOM. cheers, Greg