[PR #6646] [CLOSED] fix(python): decode backward-compatible TYPE_INT64 marshal constants #7385

Closed
opened 2026-11-01 21:47:29 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/6646
Author: @ezrabrilliant
Created: 10/23/2026
Status: ❌ Closed

Base: main ← Head: fix/pyc-type-int64


📝 Commits (1)

  • 2e7e248 fix(python): decode backward-compatible TYPE_INT64 marshal constants

📊 Changes

2 files changed (+36 additions, -0 deletions)

View changed files

📝 src/python/PythonPycParser.test.ts (+22 -0)
📝 src/python/PythonPycParser.ts (+14 -0)

📄 Description

Summary

Fixes #6609. The inspect-python-pyc command rejected a pyc whose integer
constant uses the backward-compatible marshal TYPE_INT64 tag (0x49) with
invalid_format / Unsupported marshal type 0x49., even though CPython retains
the r_long64 reader. Encoding the same integer with TYPE_INT decodes with
complete coverage.

Problem and expected behavior

Smallest trigger: a CPython 3.11-layout pyc whose constant is integer 42
encoded as TYPE_INT64 (0x49 followed by an 8-byte little-endian value).
Observed: the marshal reader has no TYPE_INT64 case, so it falls through to
Unsupported marshal type 0x49.. Expected: decode it like TYPE_INT, yielding
{"kind":"int","bits":6,"value":"42"}. CPython 3.11/3.13 sources keep the
TYPE_INT64 reader for backward compatibility.

Change and scope

Add the TYPE_INT64 tag and an i64() reader that decodes an 8-byte
little-endian signed integer (readBigInt64LE), returning the same
{ kind: "int", value, bits } shape as TYPE_INT via smallBitLength. The
reader mirrors the existing i32()/f64() bounds checks. No schema or contract
change; this only admits a marshal tag CPython already accepts.

Contract and boundary impact

  • Semantic owner and earliest changed stage: MarshalReader in
    src/python/PythonPycParser.ts, at marshal constant decoding.

  • Contribution scope fit and linked maintainer decision: ordinary fix within an
    existing boundary; no maintainer scope decision required (not applicable).

  • CLI and MCP/tool-catalog contract: no schema change. A TYPE_INT64 constant
    now decodes to an int instead of returning invalid_format.

  • Provider, bridge, target-format, or platform compatibility: none.

  • Evidence, artifact, provenance, or reconstruction contract: none; adds
    coverage for a retained CPython marshal type.

  • Target selection, authority, upstream behavior, and cleanup details: not applicable.

  • Generated metadata, package, or installation impact: none.

  • Read existing files or captured data.

  • Launch or attach to a process.

  • Inject instrumentation or run scripts/code.

  • Change process memory, registers, files, or configuration.

  • Contact network services.

  • Recover protected code or work around protections.

  • Documentation or usability only; no target interaction.

  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: src/python/PythonPycParser.test.ts — new case
    "accepts backward-compatible TYPE_INT64 marshal integer constants" covering a
    small value (42), a value with its high 32 bits set (0x1_0000_002a, proving
    the full 64-bit width is read), and a negative value (-5).

  • Base reproduction (executed): with the parser change stashed, the new test
    fails with PythonPycFormatFailure: Unsupported marshal type 0x49.; with the
    fix it decodes { kind: "int", bits: 6, value: "42" } and the 33-bit and
    negative cases.

  • User-visible CLI/MCP output: a TYPE_INT64 constant now appears as an int
    constant instead of an AnalysisInputError (invalid_format). The
    parser-to-service mapping is source-derived (PythonPycService); the full CLI
    was not executed.

  • Remaining proof gaps: no end-to-end CLI JSON captured; validated against a
    synthetic fixture, not a CPython-produced TYPE_INT64 file.

  • Observed, derived, and inferred claims remain distinguishable.

  • Artifact identity, source provenance, and failed attempts remain preserved.

  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

  • npm run test:local -- src/python/PythonPycParser.test.ts src/application/python/PythonPycService.test.ts src/artifacts/pyinstaller/MarshalSubset.test.ts — 63 passed (incl. new regression).
  • Base reproduction: same command with the parser change stashed — the new test fails with Unsupported marshal type 0x49.
  • npm run check:fast — typecheck + lint: 2 tasks successful.

Compatibility, safety, and release

  • Breaking changes or migration steps: none. Previously rejected TYPE_INT64
    inputs now decode; no existing accepted input changes.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: none; pure parser decode
    addition, no target execution.

Author readiness

Human owner: @ezrabrilliant

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VkKgC2HYpt7rG38FnoufT1


🔄 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/6646 **Author:** [@ezrabrilliant](https://github.com/ezrabrilliant) **Created:** 10/23/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/pyc-type-int64` --- ### 📝 Commits (1) - [`2e7e248`](https://github.com/morluto/rea/commit/2e7e248a27d6059c94fc7ebddfebe60e0b720654) fix(python): decode backward-compatible TYPE_INT64 marshal constants ### 📊 Changes **2 files changed** (+36 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `src/python/PythonPycParser.test.ts` (+22 -0) 📝 `src/python/PythonPycParser.ts` (+14 -0) </details> ### 📄 Description ## Summary Fixes #6609. The `inspect-python-pyc` command rejected a pyc whose integer constant uses the backward-compatible marshal `TYPE_INT64` tag (`0x49`) with `invalid_format` / `Unsupported marshal type 0x49.`, even though CPython retains the `r_long64` reader. Encoding the same integer with `TYPE_INT` decodes with complete coverage. ## Problem and expected behavior Smallest trigger: a CPython 3.11-layout pyc whose constant is integer `42` encoded as `TYPE_INT64` (`0x49` followed by an 8-byte little-endian value). Observed: the marshal reader has no `TYPE_INT64` case, so it falls through to `Unsupported marshal type 0x49.`. Expected: decode it like `TYPE_INT`, yielding `{"kind":"int","bits":6,"value":"42"}`. CPython 3.11/3.13 sources keep the `TYPE_INT64` reader for backward compatibility. ## Change and scope Add the `TYPE_INT64` tag and an `i64()` reader that decodes an 8-byte little-endian signed integer (`readBigInt64LE`), returning the same `{ kind: "int", value, bits }` shape as `TYPE_INT` via `smallBitLength`. The reader mirrors the existing `i32()`/`f64()` bounds checks. No schema or contract change; this only admits a marshal tag CPython already accepts. ## Contract and boundary impact - Semantic owner and earliest changed stage: `MarshalReader` in `src/python/PythonPycParser.ts`, at marshal constant decoding. - Contribution scope fit and linked maintainer decision: ordinary fix within an existing boundary; no maintainer scope decision required (not applicable). - CLI and MCP/tool-catalog contract: no schema change. A `TYPE_INT64` constant now decodes to an `int` instead of returning `invalid_format`. - Provider, bridge, target-format, or platform compatibility: none. - Evidence, artifact, provenance, or reconstruction contract: none; adds coverage for a retained CPython marshal type. - Target selection, authority, upstream behavior, and cleanup details: not applicable. - Generated metadata, package, or installation impact: none. - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `src/python/PythonPycParser.test.ts` — new case "accepts backward-compatible TYPE_INT64 marshal integer constants" covering a small value (`42`), a value with its high 32 bits set (`0x1_0000_002a`, proving the full 64-bit width is read), and a negative value (`-5`). - Base reproduction (executed): with the parser change stashed, the new test fails with `PythonPycFormatFailure: Unsupported marshal type 0x49.`; with the fix it decodes `{ kind: "int", bits: 6, value: "42" }` and the 33-bit and negative cases. - User-visible CLI/MCP output: a `TYPE_INT64` constant now appears as an `int` constant instead of an `AnalysisInputError` (`invalid_format`). The parser-to-service mapping is source-derived (`PythonPycService`); the full CLI was not executed. - Remaining proof gaps: no end-to-end CLI JSON captured; validated against a synthetic fixture, not a CPython-produced `TYPE_INT64` file. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run test:local -- src/python/PythonPycParser.test.ts src/application/python/PythonPycService.test.ts src/artifacts/pyinstaller/MarshalSubset.test.ts` — 63 passed (incl. new regression). - Base reproduction: same command with the parser change stashed — the new test fails with `Unsupported marshal type 0x49.` - `npm run check:fast` — typecheck + lint: 2 tasks successful. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Previously rejected `TYPE_INT64` inputs now decode; no existing accepted input changes. - Real Hopper/Ghidra, browser, or OS coverage: not applicable. - Package or release metadata impact: none. - Security, privacy, process, or containment review: none; pure parser decode addition, no target execution. ## Author readiness Human owner: @ezrabrilliant - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01VkKgC2HYpt7rG38FnoufT1 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-11-01 21:47:29 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#7385
No description provided.