1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
use NonNull;
use crateVmemError;
use cratePAGE;
use crate;
use crateReservation;
/// A contract violation (bad `size`/`align`) returns
/// [`VmemError::invalid_argument`] without touching the OS.
pub
/// Private helper: validate `initial_commit` for lazy reservations.
/// Only called from `try_reserve_aligned_lazy`, which is itself gated on
/// `lazy-commit` -- dead code when that feature is off.
///
/// On Windows, `VirtualAlloc(MEM_COMMIT)` operates on whole runtime pages,
/// and `try_commit_range` accepts only offsets that are multiples of `page_size()`.
/// Therefore, both `size` and `initial_commit` must be multiples of the runtime
/// page size to avoid creating unwritable tails. This is a fail-closed check:
/// reject requests that would create spans that cannot be fully committed via the
/// public API.
///
/// **Why this check is NOT `#[cfg(windows)]`-gated, even though the hazard it
/// prevents is Windows-only** (task #1037, finding R6-2, which is itself
/// scoped "platform-specific ... on Windows"): on Unix,
/// `reserve_aligned_lazy_raw` IGNORES `initial_commit` entirely and delegates
/// straight to `reserve_aligned_raw` — the whole span is committed by the
/// `mmap` itself, so an uncommittable tail cannot exist there. A Unix-only
/// caller therefore loses nothing real by this rejection and gains nothing
/// real from being allowed through.
///
/// The rejection is uniform anyway because the alternative is worse: a caller
/// developing on x86-64 Linux who passes a `PAGE`-multiple that is not a
/// `page_size()` multiple writes code that is silently broken the moment it
/// runs on Windows with a larger runtime page — and the crate would have
/// accepted it on every host they tested. Note that a per-OS `#[cfg]` would
/// NOT buy portability either: `page_size()` is a RUNTIME value, so the same
/// call already differs between a 4 KiB x86-64 host and a 16 KiB Apple
/// Silicon one. There is no portable compile-time constant to validate
/// against, which is exactly why the contract is stated in terms of
/// `page_size()` and enforced everywhere.
///
/// Concrete cost of the uniform rule, stated so it is not a surprise: on a
/// 16 KiB-page host, `reserve_aligned_lazy(size, align, PAGE)` is now
/// rejected, where before it was accepted and worked (harmlessly, since Unix
/// ignores the argument). `PAGE` is a compile-time floor, not the runtime
/// page size; callers must pass a `page_size()` multiple.
pub
/// Private struct for raw reservation results from backend functions.
/// Named to prevent transposing `base` and `reservation` (both `NonNull<u8>`).
///
/// This is call-site convenience only: the backend functions themselves still
/// return unnamed tuples, and the struct is constructed only at the call sites
/// via `.map()`. This helps at the call site but does NOT eliminate the
/// transposition risk entirely — the two `NonNull<u8>` tuple elements are still
/// unnamed at the backend layer.
pub
/// Private helper: finish a reservation from a raw backend result.
pub
/// Private helper: finish a reservation from a raw backend result (4-tuple).
/// Only called from `try_reserve_aligned_huge`, which is itself gated on
/// `huge-pages` -- dead code when that feature is off.
pub