node:buffer: match current kMaxLength and MAX_LENGTH values

[andrewtdiz]

Summary

Perry exposes node:buffer length constants, but current origin/main hardcodes buffer.kMaxLength and buffer.constants.MAX_LENGTH to 4294967296. Current 64-bit Node reports 9007199254740991 for both values.

The existing granular parity case only checks that the top-level and nested aliases are equal to each other, so a wrong shared value can pass.

No local Perry binary was available in this issue-creator workspace, so this report is based on current origin/main source inspection plus the Node oracle below.

Node oracle

Node v25.9.0 on this 64-bit macOS host:

const { constants, kMaxLength, kStringMaxLength } = require('node:buffer');

console.log(process.version);
console.log(constants.MAX_LENGTH, kMaxLength, constants.MAX_LENGTH === kMaxLength);
console.log(constants.MAX_STRING_LENGTH, kStringMaxLength, constants.MAX_STRING_LENGTH === kStringMaxLength);
console.log(Object.keys(constants).sort().join(','));

Output:

v25.9.0
9007199254740991 9007199254740991 true
536870888 536870888 true
MAX_LENGTH,MAX_STRING_LENGTH

Perry evidence

Current origin/main source:

• crates/perry-runtime/src/object/native_module.rs returns 4294967296.0 for ("buffer", "kMaxLength").
• The same file returns 4294967296.0 for ("buffer.constants", "MAX_LENGTH").
• kStringMaxLength / MAX_STRING_LENGTH are already set to 536870888.0, matching the Node probe above.
• crates/perry-runtime/src/buffer/validate.rs documents Node's buffer.constants.MAX_LENGTH as 2^53 - 1 on 64-bit platforms and uses 9_007_199_254_740_991.0 for validation, so the exported constant is inconsistent with Perry's own validation limit.
• test-parity/node-suite/buffer/properties/constants.ts currently checks only type and alias equality, not the actual Node value.

Suggested parity coverage

Strengthen the existing constants test to include the current Node value for the target runtime:

import { constants, kMaxLength, kStringMaxLength } from 'node:buffer';

console.log('max length:', constants.MAX_LENGTH);
console.log('top max length:', kMaxLength);
console.log('same max:', constants.MAX_LENGTH === kMaxLength);
console.log('string max:', constants.MAX_STRING_LENGTH);
console.log('top string max:', kStringMaxLength);
console.log('same string max:', constants.MAX_STRING_LENGTH === kStringMaxLength);
console.log('keys:', Object.keys(constants).sort().join(','));

If Perry intentionally clamps allocation to a lower implementation limit, that should be enforced by allocation errors separately; the public Node constant should still match Node's current value for feature detection and userland validation logic.

Scope / non-goals

This is not about exposing buffer.constants itself; that was handled by merged PR #906. It is also not asking Perry to allocate multi-terabyte buffers. The issue is the observable public constant value and its consistency with kMaxLength / constants.MAX_LENGTH.

Duplicate searches performed before filing:

• kMaxLength MAX_LENGTH 4294967296
• buffer.constants.MAX_LENGTH kMaxLength
• Buffer constants MAX_LENGTH
• PR search for kMaxLength MAX_LENGTH 4294967296 buffer.constants

[andrewtdiz]

I am taking this one and will open a focused PR for the current Node node:buffer length constants with parity coverage.

[andrewtdiz]

Opened PR: #2678

Implemented the Node-compatible node:buffer length constant surface:

• kMaxLength and constants.MAX_LENGTH now report 9007199254740991
• kStringMaxLength / constants.MAX_STRING_LENGTH remain at the Node-matching string limit
• Object.keys(constants) now exposes MAX_LENGTH,MAX_STRING_LENGTH for the native buffer.constants namespace

Verification:

• cargo fmt --all -- --check
• RUSTC_WRAPPER= cargo check -p perry-runtime
• PATH=/home/github-runner/actions-runner/externals/node24/bin:$PATH RUSTC_WRAPPER= ./run_parity_tests.sh --suite node-suite --module buffer --filter properties/constants
• jq empty test-parity/known_failures.json test-parity/threshold.json
• git diff --check
• ./scripts/check_file_size.sh