Skip to content

fix: throw when encoding a BigInt outside int64/uint64 range#290

Open
spokodev wants to merge 2 commits into
msgpack:mainfrom
spokodev:fix/bigint64-out-of-range-guard
Open

fix: throw when encoding a BigInt outside int64/uint64 range#290
spokodev wants to merge 2 commits into
msgpack:mainfrom
spokodev:fix/bigint64-out-of-range-guard

Conversation

@spokodev

Copy link
Copy Markdown

Problem

With useBigInt64: true, encodeBigInt64 branches only on the sign of the value and calls the native DataView.setBigUint64 / setBigInt64. Those methods truncate the value mod 2^64 instead of throwing, so a BigInt outside the representable range is silently corrupted on encode:

import { encode, decode } from "@msgpack/msgpack";

decode(encode(2n ** 64n,         { useBigInt64: true }), { useBigInt64: true }); // 0n
decode(encode(2n ** 64n + 1n,    { useBigInt64: true }), { useBigInt64: true }); // 1n
decode(encode(-(2n ** 63n) - 1n, { useBigInt64: true }), { useBigInt64: true }); // 9223372036854775807n  (sign flip)
decode(encode(-(2n ** 100n),     { useBigInt64: true }), { useBigInt64: true }); // 0n

No error is raised, so the caller has no way to notice the data loss.

Fix

The MessagePack int family is fixed 64-bit, so the only representable range for a BigInt is the union of signed int64 and unsigned uint64: [-2^63, 2^64 - 1]. This adds a range check in encodeBigInt64 that throws for anything outside that range, before the writes.

This matches how the encoder already rejects other unrepresentable inputs (too-long strings, too-large arrays/maps/binaries all throw rather than emit corrupt bytes).

Tests

Extended test/bigint64.test.ts:

  • the four out-of-range cases above now throw
  • the boundary values still round-trip: 0n, 42n, 2n ** 63n - 1n (max int64), -(2n ** 63n) (min int64), 2n ** 64n - 1n (max uint64)

Full suite: 329 passing, lint clean.

With `useBigInt64: true`, `encodeBigInt64` branched only on sign and
called the native `DataView.setBigUint64`/`setBigInt64`, which truncate
mod 2^64 without throwing. A BigInt outside the representable range was
silently corrupted on encode:

    encode(2n ** 64n,        { useBigInt64: true }) // decoded as 0n
    encode(2n ** 64n + 1n,   { useBigInt64: true }) // decoded as 1n
    encode(-(2n ** 63n) - 1n,{ useBigInt64: true }) // sign flip: 9223372036854775807n

The MessagePack int family is fixed 64-bit, so the only representable
range is the union of int64 and uint64: [-2^63, 2^64 - 1]. Add a range
check that throws for anything outside it, matching how the encoder
already rejects other unrepresentable inputs (too-long strings, too-large
arrays/maps/binaries).
Comment thread src/Encoder.ts Outdated
Comment on lines +292 to +294

private encodeBigInt64(object: bigint): void {
if (object < -(BigInt(2) ** BigInt(63)) || object > BigInt(2) ** BigInt(64) - BigInt(1)) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private encodeBigInt64(object: bigint): void {
if (object < -(BigInt(2) ** BigInt(63)) || object > BigInt(2) ** BigInt(64) - BigInt(1)) {
const INT64_MIN = -(BigInt(2) ** BigInt(63));
const UINT64_MAX = BigInt(2) ** BigInt(64) - BigInt(1);
private encodeBigInt64(object: bigint): void {
if (object < INT64_MIN || object > UINT64_MAX) {

Compute the int64/uint64 range bounds once at module load instead of on
every encodeBigInt64 call, per review feedback.
@spokodev

spokodev commented Jul 3, 2026

Copy link
Copy Markdown
Author

Done, hoisted INT64_MIN and UINT64_MAX to module constants so the bounds are computed once instead of on every encodeBigInt64 call.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants