[PR #533] [MERGED] fix(native): normalize otool line endings and strip plist JSON BOM #2054

New issue

Closed

opened 2026-10-16 21:13:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:13:46 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/533
Author: @morluto
Created: 10/5/2026
Status: ✅ Merged
Merged: 10/5/2026
Merged by: @morluto

Base: main ← Head: cleanup/native-text-robustness

📝 Commits (1)

720df27 fix(native): normalize otool line endings and strip plist JSON BOM

📊 Changes

3 files changed (+50 additions, -2 deletions)

View changed files

📝 src/native/parsers/otool.ts (+12 -1)
📝 src/native/parsers/plist.ts (+2 -1)
➕ tests/boundary/providers/native/nativeTextRobustness.test.ts (+36 -0)

📄 Description

Follow-up sweep: native text-boundary robustness.

parseOtoolLoadCommands split load-command/section boundaries on a bare \n. Under a CRLF capture the terminator was swallowed, so segments[].sections came back empty while section lines leaked into the command-level fields — a silent data loss matching the removed collectFlags conflation class. Line endings are normalized once at the parse boundary so every downstream matcher sees one form. Verified both directions: CRLF now parses identically to LF, and no sectname appears in command fields.
parsePlistJson fed output straight to JSON.parse, which rejects a leading U+FEFF outright, so a BOM-prefixed plutil capture turned every bundle.* field into null. Now strips one leading BOM.

Note on a claim I did not act on: I checked whether the offset symbol sentinel in parseDyldSymbols and the Non-fat file: prefix were BOM-fragile (suggested in review) — JS \s and String.prototype.trim both treat U+FEFF as whitespace, so both already handle a BOM. No change needed.

Tests: new nativeTextRobustness suite (CRLF equivalence, no field leakage, BOM plist). All 13 native boundary files pass, tsc + prettier green.

_{🔄 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/533 **Author:** [@morluto](https://github.com/morluto) **Created:** 10/5/2026 **Status:** ✅ Merged **Merged:** 10/5/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `cleanup/native-text-robustness` --- ### 📝 Commits (1) - [`720df27`](https://github.com/morluto/rea/commit/720df27592192d2c028415f5c0567ecceb83c3c6) fix(native): normalize otool line endings and strip plist JSON BOM ### 📊 Changes **3 files changed** (+50 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/native/parsers/otool.ts` (+12 -1) 📝 `src/native/parsers/plist.ts` (+2 -1) ➕ `tests/boundary/providers/native/nativeTextRobustness.test.ts` (+36 -0) </details> ### 📄 Description Follow-up sweep: native text-boundary robustness. - `parseOtoolLoadCommands` split load-command/section boundaries on a bare `\n`. Under a CRLF capture the terminator was swallowed, so `segments[].sections` came back empty while section lines leaked into the command-level `fields` — a silent data loss matching the removed `collectFlags` conflation class. Line endings are normalized once at the parse boundary so every downstream matcher sees one form. Verified both directions: CRLF now parses identically to LF, and no `sectname` appears in command fields. - `parsePlistJson` fed `output` straight to `JSON.parse`, which rejects a leading U+FEFF outright, so a BOM-prefixed plutil capture turned every `bundle.*` field into null. Now strips one leading BOM. Note on a claim I did *not* act on: I checked whether the `offset symbol` sentinel in `parseDyldSymbols` and the `Non-fat file:` prefix were BOM-fragile (suggested in review) — JS `\s` and `String.prototype.trim` both treat U+FEFF as whitespace, so both already handle a BOM. No change needed. Tests: new nativeTextRobustness suite (CRLF equivalence, no field leakage, BOM plist). All 13 native boundary files pass, tsc + prettier green. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:13:46 +00:00