[agourakis82]

Keep slice iterator pointers within the image buffer at line and slice boundaries. Preserve traversal indices and add forward/reverse regression coverage for const and mutable iterators.

Reason

Line and slice end indices can lie outside the allocated pixel array. Updating the raw pointer to those positions, or passing through an out-of-allocation intermediate position during a transition, violates the C++ pointer-addition rules.

Keep the existing indices as end markers and reconstruct the pointer only when the index is inside the iteration region. Interior increments and decrements retain direct pointer movement. Returning from a line marker restores the pointer from its index. No object fields are added.

The original ImageToVideoFilterTest is unchanged. This does not establish the cause of the historical Rosetta pixel mismatch discussed in #7015.

Local validation

C++23, AppleClang 21, x86_64 under Rosetta, with pinned existing ITK static support libraries. These are focused harness builds, not a clean full ITK build or a completed upstream CI matrix.

• Three new GTests pass with the patch and fail with the unmodified iterator headers.
• Coverage includes 2D/3D/4D, every distinct first/second axis pair, const/mutable iterators, forward/reverse traversal, nonzero buffered indices, full regions and singleton-axis subregions. Checks include pointer bounds, index/pixel agreement, exact region coverage, returning from line markers and GoToBeginOfSlice.
• The same three tests pass with AddressSanitizer and UndefinedBehaviorSanitizer; support libraries are not instrumented, and leak detection is disabled.
• Unmodified itkImageSliceIteratorTest passes.
• Unmodified itkImageToVideoFilterTest passes with output byte-identical to its baseline.
• Official pre-commit, prepare-commit-msg and commit-msg hooks pass.

Official checks pass on the maintainer-rebased head 0a1ffa7: Ubuntu ARM, Rosetta, Pixi C++ on Ubuntu/Windows/macOS, Python builds, documentation, pre-commit, CDash and the ASV comparison job. Passing the ASV job alone is not a claim of performance improvement.

The maintainer dropped the separate Indent header repair during rebase because merged #7028 already supplies that fix. The PR now contains only the slice-iterator change and its regression coverage.

Assistance

Substantive assistance covered source analysis, implementation, regression tests and auxiliary review. Readiness remains subject to human review and the full CI matrix.

[hjmjohnson]

@agourakis82 Rebased on main. The COMP: Make the Indent header self-contained commit was dropped because #7028 (merged) already fixes the same itkIndent.h include cycle; the slice-iterator commit is unchanged. Pull with git pull --rebase before pushing again.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Keeps slice iterator pointers inside the image buffer while preserving traversal indices.

• Slice iterators keep their pointers inside the image buffer.

_{Reviews (1) · Last reviewed commit: "BUG: Keep slice iterator pointers within..." · Reviewed by Greptile}

[hjmjohnson]

Thanks @agourakis82 for the analysis and the regression tests; the out-of-buffer pointer values at the end-of-line and end-of-slice markers are real, and your tests pinned them down.

I measured this change on the documented slice loop over a float 3-D image, best of 7 interleaved runs: x86 GCC 13 +196% to +208% wall time on 64^3 and 256^3 images, x86 Clang 18 +141% to +242%, arm64 Clang +3% to +7% on long lines and +79% on 2-pixel lines. The cause is the second assignment path to m_Position inside operator++/operator--, which stops the compiler from keeping the iterator in registers; inlining UpdatePosition or reducing the comparisons does not change it. On main the marker pointers are never dereferenced or compared, and ASan, UBSan and valgrind are silent on all three compilers, so there is no observable defect to weigh against that cost.

Closing in favor of #7111, which performs the same pointer steps through the pointer's integer value: no new branch, the generated loop unchanged on Clang, one extra instruction per pixel on GCC. That PR is a WIP and may itself be closed in favor of documenting the invariant.