proofs.rs

Clarify the exact slice length required by FixedInt methods

Clarify the exact slice length required by FixedInt methods

Found in Report #10 v1 · Updated 2026-10-28 13:59 UTC

Description

The FixedInt documentation describes failure when the destination has insufficient space, but does not state that a larger slice is also rejected by the built-in implementations.

Steps to Reproduce

Cargo.toml:

[package]
name = "integer-encoding-repro"
version = "0.1.0"
edition = "2021"

[dependencies]
integer-encoding = "=4.1.0"

src/main.rs:

use integer_encoding::FixedInt;

fn main() {
    let mut dst = [0xaa; 5];
    assert_eq!(42_u32.encode_fixed(&mut dst), None);
    assert_eq!(dst, [0xaa; 5]);
    assert_eq!(u32::decode_fixed(&dst), None);
}

Run cargo run.

Observed: For u32, the five-byte destination and input are rejected; encoding leaves the destination unchanged. The documentation mentions insufficient space, while the built-in implementation accepts exactly size_of::<Self>() bytes.

Please clarify the exact-length requirement for encoding and decoding, including oversized slices. The current wording is ambiguous; this report does not assume that it promises oversized destinations will succeed. The reproducer passed in debug and release with Rust 1.91.1 on macOS arm64 and default features. Later versions have not been checked.

Change history
  1. v1 · created · 2026-10-28 13:59 UTC
    {
      "title": "Clarify the exact slice length required by FixedInt methods",
      "body": "## Description\n\nThe `FixedInt` documentation describes failure when the destination has insufficient space, but does not state that a larger slice is also rejected by the built-in implementations.\n\n## Steps to Reproduce\n\n`Cargo.toml`:\n\n```toml\n[package]\nname = \"integer-encoding-repro\"\nversion = \"0.1.0\"\nedition = \"2021\"\n\n[dependencies]\ninteger-encoding = \"=4.1.0\"\n```\n\n`src/main.rs`:\n\n```rust\nuse integer_encoding::FixedInt;\n\nfn main() {\n    let mut dst = [0xaa; 5];\n    assert_eq!(42_u32.encode_fixed(&mut dst), None);\n    assert_eq!(dst, [0xaa; 5]);\n    assert_eq!(u32::decode_fixed(&dst), None);\n}\n```\n\nRun `cargo run`.\n\n**Observed:** For `u32`, the five-byte destination and input are rejected; encoding leaves the destination unchanged. The [documentation](https://github.com/dermesser/integer-encoding-rs/blob/e0a10d01e86a38d0df177676c62f9a10c845ab53/src/fixed.rs#L13-L24) mentions insufficient space, while the [built-in implementation](https://github.com/dermesser/integer-encoding-rs/blob/e0a10d01e86a38d0df177676c62f9a10c845ab53/src/fixed.rs#L39-L57) accepts exactly `size_of::<Self>()` bytes.\n\nPlease clarify the exact-length requirement for encoding and decoding, including oversized slices. The current wording is ambiguous; this report does not assume that it promises oversized destinations will succeed. The reproducer passed in debug and release with Rust 1.91.1 on macOS arm64 and default features. Later versions have not been checked.",
      "validity": "reported",
      "upstream_status": "not_reported"
    }

Read and join the discussion on the report →