Clippy lint · Suspicious · checked with Clippy 0.1.99

clippy::repr_packed_without_abi: item uses `packed` representation without ABI-qualification

What it meansChecks for items with #[repr(packed)]-attribute without ABI qualification It is in the suspicious group and warns by default.

What you see

warning: item uses `packed` representation without ABI-qualification
 --> main.rs:4:1
  |
3 |   #[repr(packed)]
  |          ------ `packed` representation set here
4 | / struct NetworkPacketHeader {
5 | |     header_length: u8,
6 | |     header_version: u16
7 | | }
  | |_^
  |
  = warning: unqualified `#[repr(packed)]` defaults to `#[repr(Rust, packed)]`, which has no stable ABI
  = help: qualify the desired ABI explicitly via `#[repr(C, packed)]` or `#[repr(Rust, packed)]`
  = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#repr_packed_without_abi
  = note: `#[warn(clippy::repr_packed_without_abi)]` on by default

Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.

Does it matter?

Without qualification, repr(packed) implies repr(Rust). The Rust-ABI is inherently unstable. While this is fine as long as the type is accessed correctly within Rust-code, most uses of #[repr(packed)] involve FFI and/or data structures specified by network-protocols or other external specifications. In such situations, the unstable Rust-ABI implied in #[repr(packed)] may lead to future bugs should the Rust-ABI change. In case you are relying on a well defined and stable memory layout, qualify the type’s representation using the C-ABI. Otherwise, if the type in question is only ever accessed from Rust-code according to Rust’s rules, use the Rust-ABI explicitly.

Code that is most likely wrong or useless. Warns by default.

How to fix it

Clippy does not fix this one automatically. Change the code by hand:

Flagged

#[repr(packed)]
struct NetworkPacketHeader {
    header_length: u8,
    header_version: u16
}

Write this instead

#[repr(C, packed)]
struct NetworkPacketHeader {
    header_length: u8,
    header_version: u16
}

Turn it off, or on

Allow it where it does not fit your code, as narrowly as you can:

On one item

#[allow(clippy::repr_packed_without_abi)]
fn my_function() { /* ... */ }

Whole crate (Cargo.toml)

[lints.clippy]
repr_packed_without_abi = "allow"

One run

cargo clippy -- -A clippy::repr-packed-without-abi

The [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.

Suspiciousgroup

warndefault level

nofixed by cargo clippy --fix

1.85.0added in Rust

Clippy's own documentation

What it does

Checks for items with #[repr(packed)]-attribute without ABI qualification

Why is this bad?

Without qualification, repr(packed) implies repr(Rust). The Rust-ABI is inherently unstable. While this is fine as long as the type is accessed correctly within Rust-code, most uses of #[repr(packed)] involve FFI and/or data structures specified by network-protocols or other external specifications. In such situations, the unstable Rust-ABI implied in #[repr(packed)] may lead to future bugs should the Rust-ABI change.

In case you are relying on a well defined and stable memory layout, qualify the type’s representation using the C-ABI. Otherwise, if the type in question is only ever accessed from Rust-code according to Rust’s rules, use the Rust-ABI explicitly.

Example

#[repr(packed)]
struct NetworkPacketHeader {
    header_length: u8,
    header_version: u16
}

Use instead:

#[repr(C, packed)]
struct NetworkPacketHeader {
    header_length: u8,
    header_version: u16
}

From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.

Up next

Also worth your time

Did this answer your question?