mirror of
https://github.com/RustPython/RustPython.git
synced 2026-10-28 18:59:04 +08:00
hyoinandout
c857f3acfd
get_find_range clamped end up to start, so an inverted range such as (2, 1) became the empty-but-valid range (2, 2). A real subsequence then found nothing there, which looked right, but the empty subsequence matched and both methods reported a hit where CPython reports -1. rfind also returned the start of the range for an empty subsequence, because its body was copied from find and the returned edge was never adjusted. An empty subsequence matches at the edge the scan begins from, so a reverse scan must report the end. Dropping the clamp lets an inverted range stay inverted and be rejected explicitly. find and rfind now share find_inner, which keeps the two directions from drifting apart again, and it checks the mmap is open before inspecting the subsequence, so find(b"") on a closed mmap raises ValueError instead of returning a position. m = mmap.mmap(-1, 3); m[:] = b"abc" m.rfind(b"") # was 0, now 3 m.rfind(b"", 1, 2) # was 1, now 2 m.find(b"", 2, 1) # was 2, now -1 m.rfind(b"", 2, 1) # was 2, now -1 Verified on macOS arm64 against CPython 3.14.7 with a 19-case table covering both methods over empty and non-empty subsequences, clamped, negative and inverted ranges: 8 mismatches before, none after. The added snippet assertions fail on the unpatched build and pass on CPython 3.14.7 as well. test_mmap, cargo fmt --check and cargo clippy -p rustpython-stdlib -D warnings are clean. Fixes #8722 Assisted-by: Claude Code:claude-opus-5