Deep Review: 20260405-232458-pr-2639

The length operator returns byte count, but sliceStringNode uses rune count. For multibyte strings, length-based arithmetic produces wrong slice results. This is not merely masked by clamping — it actively produces incorrect output:

$ echo '"café"' | yq '(. | length) as $n | .[($n - 2):]'
é           # WRONG — expected "fé" (last 2 chars)

$ echo '"café"' | yq '.[-2:]'
fé          # correct with negative index

The match operator's byte offsets at operator_strings.go:292 have the same issue: feeding match("latte").offset into a slice on a multibyte string yields wrong boundaries.

jq is internally consistent: "café" | length returns 4 (characters), and slicing is character-based. This PR correctly chose rune-based slicing but did not update the pre-existing byte-based length operator. (important, gap)

Fix: Update lengthOperator to use len([]rune(candidate.Value)) for non-null scalars, and update addMatch to convert byte offsets to rune offsets via utf8.RuneCountInString. Note: changing length is a behavioural change for multibyte strings and warrants a changelog entry.

	for el := context.MatchingNodes.Front(); el != nil; el = el.Next() {
		candidate := el.Value.(*CandidateNode)
		var length int
		switch candidate.Kind {
		case ScalarNode:
			if candidate.Tag == "!!null" {
				length = 0
			} else {
				length = len(candidate.Value)
			}
		case MappingNode:
			length = len(candidate.Content) / 2
		case SequenceNode:
			length = len(candidate.Content)
		default:
			length = 0
		}

Fix (diff):

 // operator_length.go
 case ScalarNode:
     if candidate.Tag == "!!null" {
         length = 0
     } else {
-        length = len(candidate.Value)
+        length = len([]rune(candidate.Value))
     }

The string path uses else if, so a very negative secondNumber that remains negative after adjustment never gets clamped to 0 explicitly. It works only because the later secondNumber < firstNumber guard at line 43 catches it. The array path uses separate if blocks that handle this directly. (important, regression)

func sliceStringNode(lhsNode *CandidateNode, firstNumber int, secondNumber int) *CandidateNode {
	runes := []rune(lhsNode.Value)
	length := len(runes)

	relativeFirstNumber := firstNumber
	if relativeFirstNumber < 0 {
		relativeFirstNumber = length + firstNumber
	}
	if relativeFirstNumber < 0 {
		relativeFirstNumber = 0
	}

	relativeSecondNumber := secondNumber
	if relativeSecondNumber < 0 {
		relativeSecondNumber = length + secondNumber
	} else if relativeSecondNumber > length {
		relativeSecondNumber = length
	}

	log.Debugf("sliceStringNode: slice from %v to %v", relativeFirstNumber, relativeSecondNumber)

	if relativeFirstNumber > length {
		relativeFirstNumber = length
	}
	if relativeSecondNumber < relativeFirstNumber {
		relativeSecondNumber = relativeFirstNumber
	}

	slicedString := string(runes[relativeFirstNumber:relativeSecondNumber])
	replacement := lhsNode.CreateReplacement(ScalarNode, lhsNode.Tag, slicedString)
	replacement.Style = lhsNode.Style
	return replacement
}

Fix (diff): Align the string path with the array path:

 relativeSecondNumber := secondNumber
 if relativeSecondNumber < 0 {
     relativeSecondNumber = length + secondNumber
- } else if relativeSecondNumber > length {
+ }
+ if relativeSecondNumber < 0 {
+     relativeSecondNumber = 0
+ } else if relativeSecondNumber > length {
     relativeSecondNumber = length
 }

The PR added array tests for very negative indices (.[-100:], .[:-100]) but no corresponding string tests. Also missing: Unicode strings with implicit end index, empty string slicing, and non-string scalar slicing. (important, gap)

Untested scenarios ranked by risk:

1. Unicode string with implicit end index (.greeting[2:] on "héllo") — exercises the byte-vs-rune mismatch
2. Very negative string start (.country[-100:]) — tests clamping parity with arrays
3. Very negative string end (.country[:-100]) — tests clamping parity with arrays
4. Empty string slicing (.val[0:5] on "")
5. Non-string scalar slicing (.value[0:2] on !!int)

Fix: Add test scenarios with skipDoc: true for each of these cases.

When .value[0:2] targets a !!int scalar, the string guard correctly rejects it, but the code falls through to the array path. Since Content is nil for scalar nodes, the function returns an empty sequence tagged with the scalar's type (e.g., !!int []). (important, gap)

		if lhsNode.Kind == ScalarNode && lhsNode.guessTagFromCustomType() == "!!str" {
			results.PushBack(sliceStringNode(lhsNode, firstNumber, secondNumber))
			continue
		}
		// ... falls through to array path for !!int, !!bool, !!float ...

Fix: Add an explicit guard before the array fallthrough:

 if lhsNode.Kind == ScalarNode && lhsNode.guessTagFromCustomType() == "!!str" {
     results.PushBack(sliceStringNode(lhsNode, firstNumber, secondNumber))
     continue
 }
+if lhsNode.Kind == ScalarNode {
+    return Context{}, fmt.Errorf("cannot slice scalar of type %v, only arrays and strings can be sliced", lhsNode.Tag)
+}

sliceArrayOperator uses context to evaluate index expressions via getSliceNumber. After the PR, context is lhsContext (the sliced node), not the original document context. For expressions like .a[0:.max], .max is now evaluated against .a instead of the root — producing "cannot index array with 'max'".

Before the PR, the same expression sliced the wrong target (root document instead of .a) — so this was never correct either. The PR fixed one half (correct target) without fixing the other (correct index context). (important, gap)

	if expressionNode.RHS != nil && expressionNode.RHS.RHS != nil && expressionNode.RHS.RHS.Operation.OperationType == createMapOpType {
		lhsContext, err := d.GetMatchingNodes(context, expressionNode.LHS)
		if err != nil {
			return Context{}, err
		}
		return sliceArrayOperator(d, lhsContext, expressionNode.RHS.RHS)
	}

Fix: Pass both the original context (for evaluating indices) and the LHS context (for providing nodes) to sliceArrayOperator. One approach: evaluate indices in traverseArrayOperator before calling sliceArrayOperator, then pass the resolved integers.