morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #5782] [Bug] inspect-plist truncates binary integers above UInt64.max #3510

New issue

Closed

opened 2026-10-31 00:41:18 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:41:18 +00:00

Owner

Originally created by @morluto on GitHub (Oct 21, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5782

Before submitting

I searched open and closed issues and PRs for a related report.
The reproduction contains only generated public fixture bytes.

Area

Native analysis or decompilation

Observed behavior

inspect-plist reports the accepted 16-byte binary integer 18446744073709551658 (2^64 + 42) as value: 42, with no limitation. Compiled CLI and named, SDK-validated stdio MCP agree. Python reads the full source integer. On this host, plutil -lint accepts the file, but plutil JSON/XML conversions themselves also return 42.

This is distinct from #4292/#4324 (ordinary keyed-archive integers) and #846 (unsafe JSON precision within the 64-bit range). The native conversion path loses the nonzero high half before REA parses its result.

Reproduction

From a built source checkout with locked dependencies:

work_dir="$(mktemp -d)"
python3 -I - "$work_dir/value.plist" <<'PY_FIXTURE'
import pathlib, plistlib, struct, sys
value = 2**64 + 42
body = b'bplist00' + b'\x14' + value.to_bytes(16, 'big')
data = body + b'\x08' + bytes(6) + bytes([1, 1]) + struct.pack('>QQQ', 1, 0, 25)
pathlib.Path(sys.argv[1]).write_bytes(data)
print('source:', plistlib.loads(data))
PY_FIXTURE
plutil -lint "$work_dir/value.plist"
node scripts/rea.mjs inspect-plist "$work_dir/value.plist" --json

Replayed: Python prints 18446744073709551658; lint succeeds; REA exits 0 with normalized_result.value: 42 and limitations: []. The input hash remains unchanged. An ordinary 16-byte encoding of 42 also returns 42.

Expected behavior

Preserve the exact decimal source integer, or report explicit uncertainty if it cannot be represented. Do not present its low-word fragment as an exact observed value.

Impact and scope

Incorrect numerical Evidence for this demonstrated static input. Frequency in shipped plists is NOT_ENOUGH_INFO. No target execution, input mutation, or security-boundary crossing was observed. Other integer widths are outside this report.

REA version

6.7.0; compiled baseline 3b67b362aa2cd79eac5af57d0965e81a7d0b8c2b. Current main's relevant conversion/parser path was source-checked; the runtime replay is explicitly at the baseline, not a rebuilt current main.

Runtime and platform

Node.js v24.18.0; macOS 26.3; arm64. System plutil; Python 3.14 standard-library reader.

Target and artifact context

Generated 58-byte bplist00; one signed-positive 128-bit integer record (0x14). No executable target was run.

Interface

CLI and MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Source integer: 18446744073709551658. CLI/MCP value: 42; no limitation. Root replay used the named advertised inspect_plist descriptor and SDK output validation. Source and conversion checks establish the high-half loss; no claim of production prevalence is made.

Originally created by @morluto on GitHub (Oct 21, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5782 ### Before submitting - [x] I searched open and closed issues and PRs for a related report. - [x] The reproduction contains only generated public fixture bytes. ### Area Native analysis or decompilation ### Observed behavior `inspect-plist` reports the accepted 16-byte binary integer `18446744073709551658` (`2^64 + 42`) as `value: 42`, with no limitation. Compiled CLI and named, SDK-validated stdio MCP agree. Python reads the full source integer. On this host, `plutil -lint` accepts the file, but `plutil` JSON/XML conversions themselves also return `42`. This is distinct from #4292/#4324 (ordinary keyed-archive integers) and #846 (unsafe JSON precision within the 64-bit range). The native conversion path loses the nonzero high half before REA parses its result. ### Reproduction From a built source checkout with locked dependencies: ```sh work_dir="$(mktemp -d)" python3 -I - "$work_dir/value.plist" <<'PY_FIXTURE' import pathlib, plistlib, struct, sys value = 2**64 + 42 body = b'bplist00' + b'\x14' + value.to_bytes(16, 'big') data = body + b'\x08' + bytes(6) + bytes([1, 1]) + struct.pack('>QQQ', 1, 0, 25) pathlib.Path(sys.argv[1]).write_bytes(data) print('source:', plistlib.loads(data)) PY_FIXTURE plutil -lint "$work_dir/value.plist" node scripts/rea.mjs inspect-plist "$work_dir/value.plist" --json ``` Replayed: Python prints `18446744073709551658`; lint succeeds; REA exits 0 with `normalized_result.value: 42` and `limitations: []`. The input hash remains unchanged. An ordinary 16-byte encoding of `42` also returns `42`. ### Expected behavior Preserve the exact decimal source integer, or report explicit uncertainty if it cannot be represented. Do not present its low-word fragment as an exact observed value. ### Impact and scope Incorrect numerical Evidence for this demonstrated static input. Frequency in shipped plists is `NOT_ENOUGH_INFO`. No target execution, input mutation, or security-boundary crossing was observed. Other integer widths are outside this report. ### REA version 6.7.0; compiled baseline `3b67b362aa2cd79eac5af57d0965e81a7d0b8c2b`. Current main's relevant conversion/parser path was source-checked; the runtime replay is explicitly at the baseline, not a rebuilt current main. ### Runtime and platform Node.js v24.18.0; macOS 26.3; arm64. System `plutil`; Python 3.14 standard-library reader. ### Target and artifact context Generated 58-byte `bplist00`; one signed-positive 128-bit integer record (`0x14`). No executable target was run. ### Interface CLI and MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Source integer: `18446744073709551658`. CLI/MCP value: `42`; no limitation. Root replay used the named advertised `inspect_plist` descriptor and SDK output validation. Source and conversion checks establish the high-half loss; no claim of production prevalence is made.

bsakaguchi

2026-10-31 00:41:18 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi referenced this issue

2026-10-31 01:09:31 +00:00

[PR #3522] [MERGED] fix(ci): invalidate GitHub entrypoint and package-scope caches #5799

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#3510

No description provided.

Rows
Columns