[PR #3084] [CLOSED] fix(overview)!: report uninterpretable segment lengths as unknown #5601

New issue

Closed

opened 2026-10-31 01:07:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:07:54 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/3084
Author: @kaoru0822-kitauji
Created: 10/14/2026
Status: ❌ Closed

Base: main ← Head: fix/issue-2579-segment-length

📝 Commits (1)

71e8638 fix(overview)!: report uninterpretable segment lengths as unknown

📊 Changes

3 files changed (+59 additions, -10 deletions)

View changed files

📝 src/contracts/toolOutputSchemaGroups.ts (+8 -1)
📝 src/domain/hopperValues.ts (+10 -9)
📝 tests/boundary/mcp/enhancedTools.04-uses-complete-inventories-inline.test.ts (+41 -0)

📄 Description

Closes #2579

Problem

binary_overview computes each segment's length from the provider's start/end coordinates. When the coordinates could not establish a length, addressDistance returned 0, and the overview showed it as a known zero-byte segment. That happened when a coordinate was not canonical (0X1000, not-an-address), when the endpoints were in different address spaces, or when the end came before the start. Lengths above Number.MAX_SAFE_INTEGER were clamped to that value instead of being reported as unknown.

Fix

addressDistance (the only producer of the length) now returns null in those cases. Equal canonical endpoints still give 0, and valid ranges are unchanged.
The advertised output schema makes segments[].length a nullable non-negative integer and documents when it is null.
Unlike omitted coordinates, which are already rejected, an uninterpretable range no longer causes errors or data loss. The other segments, segment_count, image_base and the procedure/string counts are all still returned.

Both live producers report exclusive ends: Ghidra uses exclusiveEnd(block) and Hopper uses start + getLength(). So canonical ranges have no off-by-one.

Validation

New MCP boundary test (binary_overview through the advertised output schema) with six ranges: equal endpoints, uppercase hex, a non-address, mixed spaces, a reversed range and a 2^53-byte range. Before the fix it returns [0, 0, 0, 0, 0, 9007199254740991]; after the fix it returns [0, null, null, null, null, null].
npm run test:focused on the 20 test files that reference binary_overview, the output schema groups or addressDistance: 241 passed, 2 skipped.
npm run check:fast, npm run docs:generate (no tracked changes) and npm run docs:check all pass.

Real-provider verification: not run. Ghidra and Hopper are not installed on this host. The fix is in provider-neutral application code, and the existing canonical-range expectations are unchanged.

BREAKING CHANGE: binary_overview segments[].length may be null when the provider coordinates do not establish an exact safe byte length.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/3084 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/14/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/issue-2579-segment-length` --- ### 📝 Commits (1) - [`71e8638`](https://github.com/morluto/rea/commit/71e8638ce306200ccd308baf69d8f14b577faa1f) fix(overview)!: report uninterpretable segment lengths as unknown ### 📊 Changes **3 files changed** (+59 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `src/contracts/toolOutputSchemaGroups.ts` (+8 -1) 📝 `src/domain/hopperValues.ts` (+10 -9) 📝 `tests/boundary/mcp/enhancedTools.04-uses-complete-inventories-inline.test.ts` (+41 -0) </details> ### 📄 Description Closes #2579 ## Problem `binary_overview` computes each segment's `length` from the provider's `start`/`end` coordinates. When the coordinates could not establish a length, `addressDistance` returned `0`, and the overview showed it as a known zero-byte segment. That happened when a coordinate was not canonical (`0X1000`, `not-an-address`), when the endpoints were in different address spaces, or when the end came before the start. Lengths above `Number.MAX_SAFE_INTEGER` were clamped to that value instead of being reported as unknown. ## Fix - `addressDistance` (the only producer of the length) now returns `null` in those cases. Equal canonical endpoints still give `0`, and valid ranges are unchanged. - The advertised output schema makes `segments[].length` a nullable non-negative integer and documents when it is `null`. - Unlike omitted coordinates, which are already rejected, an uninterpretable range no longer causes errors or data loss. The other segments, `segment_count`, `image_base` and the procedure/string counts are all still returned. Both live producers report exclusive ends: Ghidra uses `exclusiveEnd(block)` and Hopper uses `start + getLength()`. So canonical ranges have no off-by-one. ## Validation - New MCP boundary test (`binary_overview` through the advertised output schema) with six ranges: equal endpoints, uppercase hex, a non-address, mixed spaces, a reversed range and a 2^53-byte range. Before the fix it returns `[0, 0, 0, 0, 0, 9007199254740991]`; after the fix it returns `[0, null, null, null, null, null]`. - `npm run test:focused` on the 20 test files that reference `binary_overview`, the output schema groups or `addressDistance`: 241 passed, 2 skipped. - `npm run check:fast`, `npm run docs:generate` (no tracked changes) and `npm run docs:check` all pass. Real-provider verification: not run. Ghidra and Hopper are not installed on this host. The fix is in provider-neutral application code, and the existing canonical-range expectations are unchanged. BREAKING CHANGE: `binary_overview` `segments[].length` may be `null` when the provider coordinates do not establish an exact safe byte length. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:07:54 +00:00