Is it guaranteed that `align_of::<uX>() == align_of::<iX>()`?

Open
#2,155 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
documentation

Research direction

Start with the Rust Reference page on type layout and review the primitive alignment section quoted in the issue. Determine whether the documentation states or should state the relationship between signed and unsigned integer alignments, then update the relevant wording so the guarantee is explicit and verify that the page directly answers the question.

Written by the indexing model from the issue text.

Description

The reference page on type layout says:


The size of most primitives is given in this table.

Type size_of::<Type>()
bool 1
u8 / i8 1
u16 / i16 2
u32 / i32 4
u64 / i64 8
u128 / i128 16
usize / isize See below
f32 4
f64 8
char 4

usize and isize have a size big enough to contain every address on the target platform. For example, on a 32 bit target, this is 4 bytes, and on a 64 bit target, this is 8 bytes.

The alignment of primitives is platform-specific. In most cases, their alignment is equal to their size, but it may be less. In particular, i128 and u128 are often aligned to 4 or 8 bytes even though their size is 16, and on many 32-bit platforms, i64, u64, and f64 are only aligned to 4 bytes, not 8.


Is it guaranteed that the alignments of u16 and i16 are the same, that the alignments of u32 and i32 are the same, etc? It doesn't appear to be guaranteed by the text.

(Zerocopy doesn't need this – I'm just curious.)

cc @jswrenn

Dominant language
Rust
Stars
1.6k
Forks
607
Avg merge
1d 1h
Merged PRs (30d)
12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-lang/reference

All issues in rust-lang/reference

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.