Function commit_range 

pub unsafe fn commit_range(base: *mut u8, start: usize, end: usize) -> bool

Available on crate feature lazy-commit only.

Commit pages [base + start, base + end) within an existing reservation.

This is the incremental-commit building block: after a reserve_aligned_lazy call that left some pages reserved-but-uncommitted, commit_range commits exactly the requested sub-range so it becomes writable. On Windows this issues VirtualAlloc(MEM_COMMIT); on Unix and under miri the pages are already accessible, so this is a no-op that always returns true.

start and end must be multiples of the runtime page size (page_size()) with start <= end. A well-formed no-op (an empty PAGE-ALIGNED range, start == end) returns true; any other contract violation (misaligned, or start > end) returns false (task #712: an earlier version of this function clamped a contract violation to the WRITE-PERMITTING true sentinel, which already caused a real crash — see https://github.com/PHPCraftdream/sefer-alloc/blob/main/docs/CORRECTNESS_OPEN_ITEMS.md item 6 for the incident this class of bug produces on Windows).

Returns true if the range is now committed, false if the OS refused (commit-charge exhaustion / true OOM) OR the offsets violated the contract above. On false the caller MUST NOT write into the range. Never panics. For the cause use try_commit_range.

Difference from recommit

recommit re-commits pages that were PREVIOUSLY committed and then decommitted via decommit. commit_range commits pages that were NEVER committed (reserved via the lazy path). The underlying Windows syscall is the same; the semantic intent differs.

Safety

base must be the as_ptr of a live reservation, and [base+start, base+end) must fall within that reservation’s usable span (i.e. end <= len). The range must be currently reserved but not yet committed (or already committed — recommitting is harmless on Windows).

Concurrent calls are safe (task #776, F14): multiple threads may call commit_range concurrently on ranges within the SAME reservation, whether the ranges overlap or not — VirtualAlloc(MEM_COMMIT) (Windows) is itself thread-safe and idempotent, and the Unix/miri backends are no-ops (the entire span is already committed eagerly on those platforms). This does NOT relax the range/liveness contract above; it only states that issuing several legal calls from different threads at once is not itself a new hazard. (Scalability caveat, not a safety one: with the fault-injection feature compiled in, the pre-syscall hook’s FAULT_STATE mutex serializes concurrent callers — see the hook comment in try_commit_range.)