fix: honour depth==0 when rdepth exceeds MAX_DEPTH on wide structures#138
Draft
Koan-Bot wants to merge 2 commits into
Draft
fix: honour depth==0 when rdepth exceeds MAX_DEPTH on wide structures#138Koan-Bot wants to merge 2 commits into
Koan-Bot wants to merge 2 commits into
Conversation
rdepth increments on every sv_clone() call, including sibling elements in flat arrays and hashes. A container with more than MAX_DEPTH elements (4000 on Linux/macOS, 2000 on Windows) pushed rdepth past the threshold, causing the iterative fallback to deep-copy elements that the caller requested to be shared (depth=0). Observable symptoms: - clone(\@big_array, 1) deep-copied elements past index ~4000 instead of sharing them — mutations through the clone were invisible to the original. - Non-clonable types (coderefs, globs) at high indices triggered a spurious "depth limit exceeded" warning. Fix: check depth==0 before the rdepth > MAX_DEPTH block so that the "share, don't clone" semantic is always honoured regardless of call count. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
install-with-cpm@v1 regressed on Perl 5.8-5.22 after a recent cpm update requiring Perl 5.24+. Bump to @v2 for action-based jobs and use direct `cpm install` in the Docker-based Linux matrix (where cpm is pre-installed). Matches the approach approved by @atoomic in PR garu#120. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Moves the
depth == 0early-return check before therdepth > MAX_DEPTHiterative fallback insv_clone().Why
rdepthincrements on everysv_clone()call — including sibling elements in flat arrays/hashes. A container with 4000+ elements pushesrdepthpastMAX_DEPTH, causing the iterative fallback to deep-copy elements that should have been shared (depth=0means "justSvREFCNT_inc").For example,
clone(\@array_of_5000_refs, 1)should shallow-copy the outer array and share every element. But elements past index ~4000 were silently deep-copied, breaking the depth contract. Non-clonable types (coderefs, globs) at high indices also triggered a spurious "depth limit exceeded" warning.How
The
depth == 0check was at line 515, after therdepth > MAX_DEPTHblock at line 440. Moved it immediately afterrdepth++, before any iterative path can intercept.Testing
New
t/28-depth-zero-wide.t(8 tests) covering:🤖 Generated with Claude Code
Quality Report
Changes: 3 files changed, 90 insertions(+), 3 deletions(-)
Code scan: clean
Tests: passed (OK)
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline