[dependabot]

Bumps packed_struct from 0.10.1 to 0.12.0.

Release notes

Sourced from packed_struct's releases.

0.12.0

This is the first release since 0.10.1. The 0.11.0 version number was used on master in the meantime but never published to crates.io, so everything below is relative to 0.10.1.

The release contains several silent wire-format fixes: some struct definitions that compiled under 0.10.1 packed and unpacked their fields at the wrong bits. They still compile, but the bytes they produce and accept are now different (and correct). If you store packed data or exchange it with other systems, read Wire-format fixes before upgrading.

Upgrade checklist

1. Search your code for exclusive byte ranges, bytes="x..y". Every one of them changes its layout, see below.
2. Check for nested structs, reserved fields or other fields of 32 bytes or more that don't start and end on a byte boundary.
3. Fix any new compile errors about field positions and sizes that disagree. Each one points at a field whose layout was previously wrong or ambiguous.
4. Upgrade the toolchain to Rust 1.85 or newer.

Wire-format fixes

These change what pack() produces and what unpack() expects for the affected structs, with no compile error or warning.

Exclusive byte ranges, bytes="x..y", were one byte short (#107)

The byte range was converted to bits as x*8 ..= (y-1)*8 - 1 instead of x*8 ..= y*8 - 1, so bytes="0..2" covered only byte 0, and bytes="1..3" only byte 1. Bit ranges (bits="x..y") and inclusive byte ranges (bytes="x..=y") were not affected.

Whenever the type still fit into the shorter range, this compiled and silently truncated the field:

#[derive(PackedStruct)]
#[packed_struct(endian="msb", bit_numbering="msb0", size_bytes="4")]
pub struct Reg {
    #[packed_field(bytes="0..4")]
    value: u32,
}

	0.10.1	0.12.0
Reg { value: 0x12345678 }.pack()	[0x34, 0x56, 0x78, 0x00], a 24-bit field	[0x12, 0x34, 0x56, 0x78]
Reg::unpack(&[0x12, 0x34, 0x56, 0x78])	value: 0x123456, the last byte ignored	value: 0x12345678

The same happened to a u64 at bytes="0..8" (packed as 56 bits), and to array fields, whose elements shrank to fit: [u8; 4] at bytes="0..4" was packed as four 6-bit elements into the first 3 bytes. Fields that didn't fit into the shorter range, like a u16 at bytes="0..2", failed to

... (truncated)

Changelog

Sourced from packed_struct's changelog.

[0.12.0] - 2026-10-01

This is the first release since 0.10.1. The 0.11.0 version number was used on master in the meantime but never published to crates.io, so everything below is relative to 0.10.1.

The release contains several silent wire-format fixes: some struct definitions that compiled under 0.10.1 packed and unpacked their fields at the wrong bits. They still compile, but the bytes they produce and accept are now different (and correct). If you store packed data or exchange it with other systems, read Wire-format fixes before upgrading.

Upgrade checklist

1. Search your code for exclusive byte ranges, bytes="x..y". Every one of them changes its layout, see below.
2. Check for nested structs, reserved fields or other fields of 32 bytes or more that don't start and end on a byte boundary.
3. Fix any new compile errors about field positions and sizes that disagree. Each one points at a field whose layout was previously wrong or ambiguous.
4. Upgrade the toolchain to Rust 1.85 or newer.

Wire-format fixes

These change what pack() produces and what unpack() expects for the affected structs, with no compile error or warning.

Exclusive byte ranges, bytes="x..y", were one byte short (#107)

The byte range was converted to bits as x*8 ..= (y-1)*8 - 1 instead of x*8 ..= y*8 - 1, so bytes="0..2" covered only byte 0, and bytes="1..3" only byte 1. Bit ranges (bits="x..y") and inclusive byte ranges (bytes="x..=y") were not affected.

Whenever the type still fit into the shorter range, this compiled and silently truncated the field:

#[derive(PackedStruct)]
#[packed_struct(endian="msb", bit_numbering="msb0", size_bytes="4")]
pub struct Reg {
    #[packed_field(bytes="0..4")]
    value: u32,
}

	0.10.1	0.12.0
Reg { value: 0x12345678 }.pack()	[0x34, 0x56, 0x78, 0x00], a 24-bit field	[0x12, 0x34, 0x56, 0x78]
Reg::unpack(&[0x12, 0x34, 0x56, 0x78])	value: 0x123456, the last byte ignored	value: 0x12345678

The same happened to a u64 at bytes="0..8" (packed as 56 bits), and to array fields, whose elements shrank to fit: [u8; 4] at bytes="0..4" was packed as four 6-bit elements into the first 3 bytes. Fields that didn't fit into the shorter range, like a u16 at bytes="0..2", failed to

... (truncated)

Commits

• 9d05db2 Merge pull request #121 from hashmismatch/byte-order-lsb
• 4e28719 Add byte_order="lsb" for little-endian bitfield structures
• 41b1572 Document the packing table and the runtime display
• b954d76 Merge pull request #120 from hashmismatch/docs-changelog-enum-fixes
• bb533c4 Document how lsb0 bit numbering works (#92)
• 869be84 Generate Bits<N> up to the full byte width
• 9d8bb4a Fix the inferred primitive type of enums
• 77375cf Document the public API and fix outdated docs
• be27832 Add a changelog
• ab8e0fd Merge pull request #119 from hashmismatch/fix-unaligned-int-packing
• Additional commits viewable in compare view