ls slice layout from its FAT table #2734

New issue

Closed

opened 2026-10-17 21:09:38 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:09:38 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1223
Author: @kaoru0822-kitauji
Created: 10/9/2026
Status: ✅ Merged
Merged: 10/9/2026
Merged by: @morluto

Base: main ← Head: test/macho-slice-host-fat-table

📝 Commits (1)

09e8a77 test(artifacts): read /bin/ls slice layout from its FAT table

📊 Changes

1 file changed (+18 additions, -4 deletions)

View changed files

📝 src/artifacts/MachOSliceArtifactReader.test.ts (+18 -4)

📄 Description

Problem

src/artifacts/MachOSliceArtifactReader.test.ts runs the slice reader against the host's real /bin/ls with system lipo, then compares each slice's byteOffset/declaredSize with hard-coded numbers from one macOS release. /bin/ls changes between releases, so on any other host the test fails on a clean main:

macOS 26.7.1 (25G241), lipo -detailed_info /bin/ls
  x86_64  offset 16384  size 48128   (test expects 48112)
  arm64e  offset 65536  size 88672   (test expects 89088)

The test fails even though the reader reports exactly what the FAT table holds. It also shows up as an unrelated failure in npm run check:changed for any change that imports the artifact readers. It will break CI too once the macOS runner image updates /bin/ls.

Change

The test now reads the expected [offset, size] pairs directly from /bin/ls's 32-bit FAT header, independently of the reader. The slice names (x86_64, arm64e), the real lipo cross-check and the comparison itself are unchanged.

Verification

npx vitest run src/artifacts/MachOSliceArtifactReader.test.ts: passes on macOS 26.7.1. On main it fails with the size mismatch above.
oxfmt and oxlint are clean.

Test-only change, so no Hopper or Ghidra verification was needed.

🤖 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/1223 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/9/2026 **Status:** ✅ Merged **Merged:** 10/9/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `test/macho-slice-host-fat-table` --- ### 📝 Commits (1) - [`09e8a77`](https://github.com/morluto/rea/commit/09e8a7712d6753ffec745ddbc6c14c32e6e65375) test(artifacts): read /bin/ls slice layout from its FAT table ### 📊 Changes **1 file changed** (+18 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/artifacts/MachOSliceArtifactReader.test.ts` (+18 -4) </details> ### 📄 Description ## Problem `src/artifacts/MachOSliceArtifactReader.test.ts` runs the slice reader against the host's real `/bin/ls` with system `lipo`, then compares each slice's `byteOffset`/`declaredSize` with hard-coded numbers from one macOS release. `/bin/ls` changes between releases, so on any other host the test fails on a clean main: ``` macOS 26.7.1 (25G241), lipo -detailed_info /bin/ls x86_64 offset 16384 size 48128 (test expects 48112) arm64e offset 65536 size 88672 (test expects 89088) ``` The test fails even though the reader reports exactly what the FAT table holds. It also shows up as an unrelated failure in `npm run check:changed` for any change that imports the artifact readers. It will break CI too once the macOS runner image updates `/bin/ls`. ## Change The test now reads the expected `[offset, size]` pairs directly from `/bin/ls`'s 32-bit FAT header, independently of the reader. The slice names (`x86_64`, `arm64e`), the real `lipo` cross-check and the comparison itself are unchanged. ## Verification - `npx vitest run src/artifacts/MachOSliceArtifactReader.test.ts`: passes on macOS 26.7.1. On main it fails with the size mismatch above. - oxfmt and oxlint are clean. Test-only change, so no Hopper or Ghidra verification was needed. 🤖 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-17 21:09:38 +00:00