[PR #690] [CLOSED] fix(native): preserve numeric-looking Mach-O identifiers #2171

New issue

Closed

opened 2026-10-16 21:15:12 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:15:12 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/690
Author: @rudycelekli
Created: 10/6/2026
Status: ❌ Closed

Base: main ← Head: fix/rea-numeric-macho-names-20261006

📝 Commits (1)

6a234e7 fix(native): preserve numeric-looking Mach-O identifiers

📊 Changes

2 files changed (+38 additions, -1 deletions)

View changed files

📝 src/native/parsers/otool.ts (+4 -1)
📝 tests/boundary/providers/native/nativeInventory.golden.test.ts (+34 -0)

📄 Description

Problem

Mach-O segment and section identifiers are text. parseFields coerces every numeric-looking otool value to a number, so real names such as segment 0001 and section 0002 become 1 and 2 in native inventory. This changes their identity and breaks matching against the actual binary's names.

Change

Preserve segname and sectname as text. Retain existing numeric parsing for offsets, sizes and other numeric fields.

Verification

An owned dylib was built with actual host clang/linker -sectcreate,0001,0002,.... Real xcrun otool -l reports the segment 0001 and section 0002.

The public filesystem target resolver and actual NativeMacOSProvider/xcrun inventory report the wrong names before the fix. After it they retain 0001 and 0002 while preserving the observed file offset 16384 and section size 8. The corrected native probe reads the public schema's segments.items and sections.items; the earlier probe's array assumption was a setup error and is not evidence for the fix.

The captured real otool regression fails before and passes after.
All 3 focused native inventory tests and all five npm run check tasks pass using Node 24.18.0 and exact locked dependencies.
The owned binary was inspected statically; no target execution, Ghidra or Hopper verification is claimed.

AI assistance was used for investigation, implementation, tests, description and independent patch review. Actual producer proof and limitations are stated above.

_{🔄 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/690 **Author:** [@rudycelekli](https://github.com/rudycelekli) **Created:** 10/6/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/rea-numeric-macho-names-20261006` --- ### 📝 Commits (1) - [`6a234e7`](https://github.com/morluto/rea/commit/6a234e79f24b85acee330a71bebf5fcc789a761b) fix(native): preserve numeric-looking Mach-O identifiers ### 📊 Changes **2 files changed** (+38 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/native/parsers/otool.ts` (+4 -1) 📝 `tests/boundary/providers/native/nativeInventory.golden.test.ts` (+34 -0) </details> ### 📄 Description ## Problem Mach-O segment and section identifiers are text. `parseFields` coerces every numeric-looking otool value to a number, so real names such as segment `0001` and section `0002` become `1` and `2` in native inventory. This changes their identity and breaks matching against the actual binary's names. ## Change Preserve `segname` and `sectname` as text. Retain existing numeric parsing for offsets, sizes and other numeric fields. ## Verification An owned dylib was built with actual host clang/linker `-sectcreate,0001,0002,...`. Real `xcrun otool -l` reports the segment `0001` and section `0002`. The public filesystem target resolver and actual `NativeMacOSProvider`/xcrun inventory report the wrong names before the fix. After it they retain `0001` and `0002` while preserving the observed file offset 16384 and section size 8. The corrected native probe reads the public schema's `segments.items` and `sections.items`; the earlier probe's array assumption was a setup error and is not evidence for the fix. - The captured real otool regression fails before and passes after. - All 3 focused native inventory tests and all five `npm run check` tasks pass using Node 24.18.0 and exact locked dependencies. - The owned binary was inspected statically; no target execution, Ghidra or Hopper verification is claimed. AI assistance was used for investigation, implementation, tests, description and independent patch review. Actual producer proof and limitations are stated above. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:15:12 +00:00