julia

76c294f9 - support: Fix Eytzinger range containment for boundaries and abutting ranges

support: Fix Eytzinger range containment for boundaries and abutting ranges The Eytzinger address-range tree used to answer "is this object inside a loaded sys/pkg image" queries encoded its range boundaries incorrectly. Range starts (img_min) were reported as outside the range and exclusive range ends (img_max) as inside it, inverting the intended half-open [start, end) semantics. Additionally, if one range ended exactly where the next began, the shared boundary and the entire interior of the following range were reported as out of range, because end boundaries sorted after coincident start boundaries. This didn't matter for images, since they had padding around them, so we would avoid those queries. But it affects the general correctness / re-usability of the data structure. Since all boundaries are 4-byte aligned, encode a start boundary s as s + 2 (even, in-range) and an end boundary e as e + 1 (odd, out-of-range) so that at a shared address the start wins the tie, and query a 4-byte aligned address with addr + 3, which is congruent to 3 (mod 4) and so never coincides with any boundary. Its strict predecessor is then the range's start boundary exactly when start <= addr < end. Also wire up a `make test` target under src/support that runs the standalone unit tests, since none were previously reachable. Fixes #61385 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>