Nov 11, 2026, 9:34 PM@jripley This is very educational. However, for purposes of my task today, imagine we care very much about BSD derived systems (MacOS 10+, and a second platform I am forbidden from speaking the name of aloud) and very little about Linux. Does your advice change?
@mcc (merging threads) Apple arm64 platforms are the cases I had in mind where you might encounter a finer granule of memory protection vs address mapping. It varies by platform (Mac vs iOS) and whether it's under emulation. I *think* this all got reconciled by simply going with the (less efficient for both hardware and software) 4KB page size, because there's too much legacy software which would otherwise break. But I'm out of usefulness here—I didn't touch any of this after shipping A7 :)
Nov 11, 2026, 10:05 PM@jripley Okay, thank you.
Repeating what you said back to you:
On normal UNIX/Linux, mmap, mprotect and mlock all use sysconf(_SC_PAGE_SIZE) multiples. But on recent MacOS, mprotect and mlock may use a different size; using sysconf(_SC_PAGE_SIZE) is always safe, but a smaller (divisor) size may potentially be allowed.
If this is correct, my question is:
How do I find out the allowed mprotect/mlock size multiple on mac?
Nov 11, 2026, 10:05 PM@jripley The MacOS 26 (on ARM) mprotect manpage reads "Not all implementations will guarantee protection on a page basis but Mac OS X's current implementation does" but does not mention sub-page arguments being legal.
@mcc (Deleted previous post) I think I'm describing behavior which never made it into releases. It looks like mmap/mlock/mprotect these days on Mac/iOS all function in the intuitive way on a 16KB granule (arm64), and the existence of smaller granules is something you'd only encounter in x86 emulation. So, looks like sanity prevailed.
Nov 11, 2026, 10:51 PM@jripley 👍 POSIX prevails