Skip to content

[RFC] Allow packed types to transitively contain aligned types #3718

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

[RFC] Allow packed types to transitively contain aligned types #3718

Changes from 3 commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
8518173
Initial writeup
PixelDust22 Oct 24, 2024
3d44198
Update PR numbers
PixelDust22 Oct 24, 2024
e77c6be
update
PixelDust22 Oct 24, 2024
af3cc30
Update
PixelDust22 Oct 25, 2024
175d29f
Updates
PixelDust22 Oct 29, 2024
a53aab1
Updates
PixelDust22 Oct 29, 2024
5190399
Update text/0000-layout-packed-aligned.md
PixelDust22 Nov 4, 2024
a12370d
Update drawbacks
PixelDust22 Nov 12, 2024
2ed92ef
Update 0000-layout-packed-aligned.md
PixelDust22 Nov 21, 2024
ee3cd02
Update based on feedback
PixelDust22 May 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
176 changes: 176 additions & 0 deletions text/0000-layout-packed-aligned.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,176 @@
- Feature Name: `layout_packed_aligned`
- Start Date: 2024-10-24
- RFC PR: [rust-lang/rfcs#3718](https://github.com/rust-lang/rfcs/pull/3718)
- Rust Issue: [rust-lang/rust#100743](https://github.com/rust-lang/rust/issues/100743)

# Summary
[summary]: #summary

This RFC makes it legal to have `#[repr(C)]` structs that are:
- Both packed and aligned.
- Packed, and transitively contains`#[repr(align)]` types.

It also introduces `#[repr(system)]` which is designed for interoperability with operating system APIs.
Copy link
Member

@scottmcm scottmcm Oct 31, 2024

Choose a reason for hiding this comment

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

I wonder if it's be worth splitting this out.

I'm a big fan of splitting repr(linear) vs repr(C) (which I think this is spelling as repr(C) vs repr(system)) to have the distinction between "the layout you get with https://doc.rust-lang.org/beta/std/alloc/struct.Layout.html#method.extend" and "whatever weird layout your C compiler uses". That distinction would be really nice for making intent clearer, since today you get "you can't do that in C" warnings sometimes just because you used repr(C) to have a predictable layout for your Rust-only code.

So I'd kinda like to consider that separately from any new packed-related stuff.

Copy link

@CAD97 CAD97 Oct 31, 2024

Choose a reason for hiding this comment

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

No, the only difference between #[repr(C)] and #[repr(system)] by this RFC is that on pc-windows-gnu #[repr(system)] is the MSVC layout while #[repr(C)] is the GCC layout. On all other targets #[repr(system)] and #[repr(C)] are identical (per this RFC).

Copy link
Member

@programmerjake programmerjake Oct 31, 2024

Choose a reason for hiding this comment

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

I think repr(linear) is independently useful and we should have all 3. that said, I am concerned that current repr(C) code often means "I want stable linear layout" rather than "I want whatever weirdness the C compiler decides to use", so I think deprecating repr(C) and replacing it with repr(linear), repr(bikeshed_other_C) and repr(system) is worth considering.

Copy link
Member

@RalfJung RalfJung Oct 31, 2024

Choose a reason for hiding this comment

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

Indeed, this RFC proposes a different distinction between repr(C) and repr(system) than what has been previously discussed in other threads.

Since the distinction between the two layouts we have here is Windows-only, I wonder if it should be some Windows-only name, like repr(msvc) or so? Is there a good reason to even make both of them available on all targets -- effectively exporting a Windows-only complication to other, saner platforms?

Copy link

@CAD97 CAD97 Oct 31, 2024

Choose a reason for hiding this comment

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

Is there a good reason to even make both of them available on all targets

The reason is that this is also how the extern "system" function ABI string works. Code uses extern "system" to link to libraries which use __stdcall on Windows platforms, and in the same way code would use #[repr(system)] for linking to a dylib which provides builds with only the MSVC toolchain for Windows targets.

I don't necessarily endorse this option, but it is logically consistent with how Rust already uses "system" as an ABI string.

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

Oops, yes, that's correct.

Copy link
Member

@joshtriplett joshtriplett Apr 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

I don't think we should introduce repr(system) here. A general mechanism with a generic name like that doesn't seem appropriate for something needed only on the windows-gnu targets for using the MSVC ABI. I'd suggest that either this should be removed from this RFC or it should be renamed to something like repr(MSVC) or repr(windows).

Copy link
Member

@RalfJung RalfJung Apr 16, 2025

Choose a reason for hiding this comment

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

We also had similar trouble with AIX, though it may seem like that can in the end be resolved without changing the layout algorithm... it's not entirely clear yet.

But more generally, we could totally encounter a target that specifies its C structs to have some funny layout rules, e.g. requiring certain things to be over-aligned. And for repr(C) on ZST, there's really nothing sensible we can do since the C ABI cannot express such types. AFAIK C compilers will typically ensure every struct has size at least 1; should we also adopt that rule and if not, why not?

Copy link
Contributor

@Jules-Bertholet Jules-Bertholet Apr 16, 2025

Choose a reason for hiding this comment

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

I don't think we should introduce repr(system) here. A general mechanism with a generic name like that doesn't seem appropriate for something needed only on the windows-gnu targets for using the MSVC ABI.

Do we know for certain that we will never get another target like this? As in, a target meant to interoperate with a non-standard C compiler for the system, with a different ABI than the standard system C compiler.

Copy link

@tmccombs tmccombs Apr 17, 2025

Choose a reason for hiding this comment

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

Suppose that we did. Would it actually be useful to have a "system" repr that could be used for both cases? I would expect most cases of such a repr would be closely tied to the OS.

It has the same behavior as `#[repr(C)]` except on `*-pc-windows-gnu` targets where it uses the msvc layout
rules instead.

# Motivation
Copy link
Contributor

@joshlf joshlf Apr 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Can we explicitly document that a goal of this RFC is to make sure that existing uses of #[repr(C)] are required to clarify their intent (ie, to indicate compatibility with a C compiler or to indicate a "linear" layout)? In particular, this implies that #[repr(C)] itself should be deprecated, and the two behaviors should both be supported by new reprs. That will ensure that code doesn't silently do either of the following:

  • Change its behavior (if we decide to change #[repr(C)] to mean "compatible with the C compiler")
  • Remain subtly buggy (if we decide to keep #[repr(C)]'s behavior, and that code was intended to be compatible with the C compiler)

Instead, deprecating #[repr(C)] will ensure that code is required to clarify its intent by upgrading to one of the newly-added reprs.

[motivation]: #motivation

This RFC enables the following struct definitions:

```rs
#[repr(C, packed(2), align(4))]
struct Foo { // Alignment = 4, Size = 8
a: u8, // Offset = 0
b: u32, // Offset = 2
}
```

This is commonly needed when Rust is being used to interop with existing C and C++ code bases, which may contain
unaligned types. For example in `clang` it is possible to create the following type definition, and there is
currently no easy way to create a matching Rust type:

```cpp
struct __attribute__((packed, aligned(4))) MyStruct {
Copy link
Member

@RalfJung RalfJung Oct 31, 2024

Choose a reason for hiding this comment

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

It is somewhat confusing that the Rust example uses packed(2) but the C example just uses packed. Would be better to make them equivalent.

uint8_t a;
uint32_t b;
};
```

Currently `#[repr(packed(_))]` structs cannot transitively contain #[repr(align(_))] structs due to differing behavior between msvc and gcc/clang.
However, in most cases, the user would expect `#[repr(C)]` to produce a struct layout matching the same type as defined by the current target.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

## `#[repr(C)]`
When `align` and `packed` attributes exist on the same type, or when `packed` structs transitively contains `align` types,
Copy link

@tmccombs tmccombs Nov 1, 2024

Choose a reason for hiding this comment

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

Is there any difference in behavior between the c, system, and rust for types with both packed and align?

My expectation would be that regardless of whether it is c, system, or rust, if I have repr(packed(2),align(4)) the alignment of the overall type is 4, and the alignment of it's fields is at most 2 unless maybe one of those fields itself has an alignment specified. My reading of the reference section agrees with that, but the guide section is a little ambiguous.

And FWIW, it would be more intuitive to me if packed ignored the alignment of field types, but had a way to specify higher alignment for individual fields.

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

As currently written, #[repr(align)] used in a field's type definition (or transitively in its fields' types') could still raise the alignment of the type beyond the minimum alignment provided by the attribute, if the "infectious" alignment is in use (MSVC layout).

In MSVC C, such would theoretically be a compilation error (alignas cannot be used to lower alignment). I don't know what the behavior of templated C++ is, actually.

This is consistent with the behavior of repr(align) for an alignment less than the alignment required for primitive field alignment.

the resulting layout matches the target toolchain ABI.
Copy link

@CAD97 CAD97 Oct 25, 2024

Choose a reason for hiding this comment

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

To verify, Clang/LLVM does replicate the MSVC behavior correctly for its MSVC target, correct? It's a harder sell to change repr(C) if extended types already weren't portable between the C++ compiler toolchains for the target.

Copy link
Author

@PixelDust22 PixelDust22 Oct 29, 2024

Choose a reason for hiding this comment

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

I do believe so.

https://clang.llvm.org/docs/MSVCCompatibility.html

First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code should be able to link against MSVC-compiled code successfully.

Record layout: Complete. We’ve tested this with a fuzzer and have fixed all known bugs.


For example, given:
```c
#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);
```
`align_of::<Bar>()` would be 4 for `*-pc-windows-msvc` and 1 for everything else.
Copy link
Contributor

@joshlf joshlf Oct 31, 2024

Choose a reason for hiding this comment

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

IMO this is extremely unintuitive behavior, especially for those of us writing custom derives (like zerocopy). We can't just rely on querying align_of - we need to be able to parse a type's definition and understand the semantics of any repr attributes on it.

Also, while this is technically not a breaking change, I wouldn't be surprised if some custom derive code implicitly assumes that this behavior isn't possible, and would become unsound in the face of this change. For example, as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change.

I'd propose that if system-specific behavior like this is required, it'd be better to do it behind a new repr so that the behavior of repr(C) remains straightforward.

Copy link

@CAD97 CAD97 Oct 31, 2024

Choose a reason for hiding this comment

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

as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change

Did you say this wrong somehow? By this RFC, align(N) types are still always aligned to at least N when behind a reference. In fact, they're aligned to N in more cases, as packed types can't underalign them with MSVC layout rules.

What changes is that packed(M) types no longer have an alignment of exactly M, but instead have an alignment of at least M.

custom derive code might be unsound

Such custom derive code is already likely quite iffy, since #[derive(Trait)] #[proc_macro] struct will have the derive see the token stream before the proc macro processes it and can modify all the decorated code arbitrarily. zerocopy is aware of this and doesn't permit any attribute it doesn't know the reserved semantics of to be in the type definition, but that's a high, difficult, and restrictive bar to clear most of the time.

Copy link
Contributor

@joshlf joshlf Nov 12, 2024

Choose a reason for hiding this comment

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

as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change

Did you say this wrong somehow? By this RFC, align(N) types are still always aligned to at least N when behind a reference. In fact, they're aligned to N in more cases, as packed types can't underalign them with MSVC layout rules.

What changes is that packed(M) types no longer have an alignment of exactly M, but instead have an alignment of at least M.

You're right, I misread the text. Still, there's a concern: Our derives currently take #[repr(C, packed(N))] as a guarantee that the decorated type cannot have alignment greater than N. This is consistent with the Reference:

For packed, ... the alignments of each field, for the purpose of positioning fields, is the smaller of the specified alignment and the alignment of the field’s type.

IIUC, to make packed no longer provide this guarantee is a breaking change with respect to the Reference.

There's another concern as well: This makes "whether or not the type has an alignment repr (packed/align)" part of the type's layout. The Reference currently specifies how types are laid out purely in terms of the sizes and alignments of their field types, and not in terms of any other facts about the field types. With this change, the following two Bar types would have different layouts despite containing Foo types with identical sizes and alignments:

#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);

#[repr(C)]
struct Foo(u8, [u32; 0]);
#[repr(C, packed(1))]
struct Bar(Foo);

Copy link
Member

@kennytm kennytm Nov 12, 2024

Choose a reason for hiding this comment

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

#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);

This does not compile today (reference said "a packed type cannot transitively contain another aligned type"), so we are free to choose whether the two Bars should have same or different layouts after this RFC.

error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type
 --> src/lib.rs:4:1
  |
4 | struct Bar(Foo);
  | ^^^^^^^^^^
  |
note: `Foo` has a `#[repr(align)]` attribute
 --> src/lib.rs:2:1
  |
2 | struct Foo(u8);
  | ^^^^^^^^^^

Copy link
Contributor

@joshlf joshlf Nov 12, 2024

Choose a reason for hiding this comment

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

My point isn't that this is a breaking change, but rather than it breaks the current mental model, which is that a type's layout is determined solely by the size and alignment of its fields. This RFC changes that to say that a type's layout is determined by the size, alignment, and representation of its fields. Since representation is a fairly complicated concept (it can include repr(C), repr(Int), repr(packed), repr(align), repr(transparent), and some-but-not-all combinations of these), IMO it significantly complicates the mental model of type layout to say that a type's layout also depends upon its fields' representations.

Copy link
Member

@RalfJung RalfJung Nov 12, 2024

Choose a reason for hiding this comment

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

Unfortunately, the existing. mental model turned out to be in contradiction to reality, at least on MSVC targets. When you build a model and then reality demonstrates the incorrectness of the model, sometimes the best option is to fix your model. Yes we documented this model in a bunch of places, but... what else could we do? Stick our head into the sand and continue pretending that the simpler model is "good enough"?

So now the layout of a type is determined by the size, alignment, and explicitly requested alignment of its fields.

Copy link

@CAD97 CAD97 Nov 12, 2024

Choose a reason for hiding this comment

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

Unfortunately, the existing mental model turned out to be in contradiction to reality, at least on MSVC targets. When you build a model and then reality demonstrates the incorrectness of the model, sometimes the best option is to fix your model.

There is another alternative: argue that because __declspec(align) and #pragma pack are nonstandard C extensions, we don't necessarily need to be layout-compatible with the system C in these cases. That's basically the argument for a struct with one zero-length array member on MSVC being zero-sized and not align-sized.

Counter to my own point, though, is that struct alignas(N) Name is standard C*++*, and the MSVC behavior is the same as with declspec in C mode. #pragma pack is still nonstandard (and I find MSVC's definition of it to be bonkers) but standard type alignas significantly weakens the argument that it isn't necessary to support.

But if there exists a type on MSVC with basic alignment higher than the default member packing level without also having an explicitly requested alignment (thus not being sufficiently aligned by default), then I would swing towards writing of MSVC layout edge cases as broken.

This does not compile today

Unfortunately,​ this error is straightforward to sidestep with generics.

#[repr(align(4))]
struct Aligned;

#[repr(packed(1))]
struct Packed<T = Aligned>(T);

fn main() {
    dbg!(align_of::<Packed>());
    // [src/main.rs:8:5] align_of::<Packed>() = 1
}

Copy link
Contributor

@joshlf joshlf Nov 18, 2024

Choose a reason for hiding this comment

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

Isn't it the case that all of these issues could be avoided by introducing a new repr rather than changing the meaning of repr(C)? I understand that, historically, repr(C) was intended to mean "does the same thing as the C compiler", but it's since come to be used for much more beyond that, and its current semantics are relied upon by a huge amount of unsafe code that would become silently unsound in the face of the changes proposed here. Is there a reason that introducing a new repr (rather than changing the meaning of repr(C)) wouldn't be the obvious solution to address all of the present concerns?

Copy link

@CAD97 CAD97 Nov 20, 2024

Choose a reason for hiding this comment

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

The counter argument is that a similarly huge amount of unsafe code exists which is relying on repr(C) meaning compatible with the target C compiler's structure layout. It comes down to which use case you consider more important.

This RFC's position is that repr(C) matching C is the more important property, and I posit that there's more generated C bindings that wouldn't get migrated to a new repr than there is relying on the exact current behavior; the latter usage is much more likely to be actively maintained and tracking this kind of development, whereas generated bindings are perceived more stable.

My personal position is that repr(C) matching the target C compiler is only relevant limited to standard C compliant structure layout, but I do see the benefits of both sides of the debate. It's unfortunately similar to splitting size_t/uintptr_t in that Rust assumes the two usages are fully identical, but edge cases mean that that aren't.



## `#[repr(system)]`
When `align` and `packed` attributes exist on the same type, or when `packed` structs transitively contains `align` types,
the resulting layout matches the target OS ABI.

For example, given:
```c
#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);
```
`align_of::<Bar>()` would be 4 for `*-pc-windows-msvc` and `*-pc-windows-gnu`. It would be 1 for everything else.



# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

In the following paragraphs, "Decreasing M to N" means:
```
if M > N {
M = n
}
```

"Increasing M to N" means:
```
if M < N {
M = N
}
```


`#[repr(align(N))]` increases the base alignment of a type to be N.

`#[repr(packed(M))]` decreases the alignment of the struct fields to be M. Because the base alignment of the type
is defined as the maximum of the alignment for any fields, this also has the indirect result of decreasing the base
alignment of the type to be M.

When the align and packed modifiers are applied on the same type as `#[repr(align(N), packed(M))]`,
the alignment of the struct fields are decreased to be M. Then, the base alignment of the type is
increased to be N.

When a `#[repr(packed(M))]` struct transitively contains a field with `#[repr(align(N))]` type,
- The field is first `pad_to_align`. Then, the field is added to the struct with alignment decreased to M. The packing requirement overrides the alignment requirement. (GCC, `#[repr(Rust)]`, `#[repr(C)]` on gnu targets, `#[repr(system)]` on non-windows targets)
Copy link

@CAD97 CAD97 Oct 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

This pad_to_align seems incorrect. If it's Layout::new::<FieldTy>().pad_to_align(), that's unnecessary; type size is already a multiple of alignment by construction. The padding in the struct is handled by adding the field as with an alignment decreased to M. packed does not ever strip trailing padding, but that's just due to said padding being part of the type, not coming from some different layout stride property.

Copy link
Author

@PixelDust22 PixelDust22 Oct 29, 2024

Choose a reason for hiding this comment

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

However, Clang and GCC has the following layout:

struct  __attribute__((aligned(4)))
MyStructInner { // Alignment = 4, Size = 4
    uint8_t a; // Offset = 0
};

struct  __attribute__((packed))
MyStruct { // Alignment = 1, Size = 8
    MyStructInner a; // Offset = 0
    uint32_t b; // Offset = 4
};

It is indeed curious that b would have offset = 4 in MyStruct, even though it's not technically necessary. This behavior was covered by the language I used in the RFC.

Copy link

@CAD97 CAD97 Oct 29, 2024

Choose a reason for hiding this comment

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

No, there's no curiosity here? MyStructInner has a size of 4, so the next field to follow it must be offset by at least 4 bytes from the field of type MyStructInner to avoid overlapping it. It's not allowed to put fields within the trailing padding of other fields in C, C++, nor Rust. (Unless using [[no_unique_address]] in C++.)

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

I think I might understand where the disconnect is coming from. MyStruct does not have the field of type uint8_t pushed into its layout; it has a field of type MyStructInner pushed into its layout, and that MyStructInner has the full size of 4 bytes.

No additional alignment needs to be applied to push the field, because the MyStructInner type is already sufficiently sized and aligned for the MyStructInner value.

Copy link
Member

@RalfJung RalfJung Nov 1, 2024

Choose a reason for hiding this comment

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

I don't even know what "the field is first pad_to_align" even means. First of all I can't quite parse it from a grammatical PoV, and secondly the output of a layout algorithm is the offset of each field of the type (that is, the immediate fields listed in the type declaration, not the recursive ones). So it's completely unclear what this business with recursive fields here is supposed to mean. It sounds like it is talking about the offset of a field of an inner type in the outer type (like, the offset of a field of MyStructInner in MyStruct), but that makes no sense.

Copy link
Author

@PixelDust22 PixelDust22 Nov 1, 2024

Choose a reason for hiding this comment

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

Ok I see where the disconnect came from as well. I was under the impression that MyStructInner would have a size of 1 byte and an alignment of 4 bytes. If MyStructInner already have a size of 4 bytes, pad_to_align is indeed not necessary, although it wouldn't be incorrect.

- The field is added to the struct with alignment increased to N. The alignment requirement overrides the packing requirement. (MSVC, `#[repr(C)]` on msvc targets, `#[repr(system)]` on windows targets)
Copy link

@CAD97 CAD97 Oct 25, 2024

Choose a reason for hiding this comment

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

The RFC should be explicit about the fact that this introduces a new kind of alignment to Rust type layout. There's the existing align_of/Layout::align, and then there's explicitly added alignment, which can be different.

Is this new alignment flavor exposed to code in any way? If so, is it included in alloc::Layout? Given Layout is part of the very performance critical allocation API, it probably shouldn't be, but then Layout isn't sufficient to compute the layout of a compound repr(C) type anymore.

Copy link
Author

@PixelDust22 PixelDust22 Oct 29, 2024

Choose a reason for hiding this comment

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

We're not introducing a new type of alignment. Conceptually:

  • packed(N) changes the alignment of the inner fields to be N.
  • aligned(M) changes the alignment of the entire structure to be M.

When both rules apply to the same type, (that's when a packed type transitively contains an aligned field), we have ambiguity, and we need some rules to determine who wins.

So really we're just changing the value returned by offset_of. align_of will continue to return the base alignment of a type like before.

Copy link

@CAD97 CAD97 Oct 29, 2024

Choose a reason for hiding this comment

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

But it is a different kind of alignment. i64 has an alignment of 8, which can be lowered by packed. #[repr(align(8))] i64 has an alignment of 8, which cannot be lowered by packed. #[repr(align(4))] i64 has an alignment of 8, which can be lowered to 4 by packed. What is this if not a new kind of alignment? Attributes apply to the type they decorate, not to all types which transitively contain the decorated type.

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

To reiterate this point: you end up with "primitive alignment" which can be suppressed by packed, originating from primitives; as well as "user alignment" which cannot be overridden by packed, originating from source attributes.

Types are not constructed as a list of primitive fields flattened from the relevant types, even as much as the MSVC layout algorithm sometimes pretends that this is the case. Types are instead defined compositionally, and a field of a struct or enum type is no different from that of some primitive type.

Copy link
Member

@RalfJung RalfJung Nov 1, 2024

Choose a reason for hiding this comment

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

And here "user alignment" would be what is ultimately returned by align_of, i.e. the alignment required for references to this type?

This reminds me a lot of the discussions around u64 on 32bit MSVC, which requires separating "alignment of references to this type" and "alignment of struct fields to this type"... is the new kind of alignment proposed in this RFC the same as as that, or does MSVC actually have 3 kinds of alignment?

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

Adding fields to core::alloc::Layout will be a difficult sell, because Layout is part of the global dynamic allocation ABI, and adding more fields to allocation queries which are not needed for the actual allocation wouldn't be very zero cost abstraction of us.

Copy link
Member

@programmerjake programmerjake Nov 1, 2024

Choose a reason for hiding this comment

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

Layout should be able to stay the same size since it can be:

pub struct OldLayout {
    size: usize,
    align: usize, // really a wrapper of a repr(usize) enum
}
pub struct NewLayout {
    size: usize,
    log2_align: u8,
    #[cfg(windows)] // or any other platforms that have msvc's weirdness
    log2_manual_align: u8,
}

Copy link
Member

@programmerjake programmerjake Nov 1, 2024

Choose a reason for hiding this comment

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

Adding fields to core::alloc::Layout will be a difficult sell,

ok, maybe make a #[cfg(windows)] MsLayout struct then?

Copy link
Member

@programmerjake programmerjake Nov 1, 2024

Choose a reason for hiding this comment

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

actually, now that I'm thinking about it, you'd probably want repr(MS) to be available on non-windows too since you'd need it in writing software like Wine where you have to interface with both the host system and with Windows programs running inside your Win32 API implementation

Copy link

@SamB SamB Aug 7, 2025

Choose a reason for hiding this comment

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

actually, now that I'm thinking about it, you'd probably want repr(MS)

Hmm, GCC does have ms_abi/sysv_abi function __attribute__s for such applications ... and also ms_struct/gcc_struct type __attribute__s, for that exact purpose.

Though I guess GCC doesn't do this perfectly, or clang wouldn't have different ABI between *-windows-msvc and *-windows-gnu (except I guess the dependency on MS CRT vs. libgcc for those little assembly-code helpers to do various arithmetic and such, and any differences due to the different headers, of course).

(Clang doesn't make any attempt to support gcc_struct; in fact, gcc_struct does not appear anywhere in the llvm source tree at the moment.)


# Drawbacks
[drawbacks]: #drawbacks
Copy link
Member

@RalfJung RalfJung Nov 1, 2024

Choose a reason for hiding this comment

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

Due to this, this RFC will actually change the layout of some types that are currently accepted on stable, on MSVC targets. That should be discussed as a drawback.


Historically the meaning of `#[repr(C)]` has been somewhat ambiguous. When someone puts `#[repr(C)]` on their struct, their intention could be one of three things:
Copy link
Member

@RalfJung RalfJung Nov 1, 2024

Choose a reason for hiding this comment

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

https://doc.rust-lang.org/reference/type-layout.html#the-c-representation actually documents the meaning of repr(C) quite clearly: it means types are laid out linearly, according to a fixed algorithm. So this RFC is proposing a breaking change, and unsafe code that relies on what is documented in the Reference might become subtly unsound if this RFC gets implemented.

That should at least be mentioned and discussed as a drawback.

Copy link
Contributor

@joshlf joshlf Nov 12, 2024

Choose a reason for hiding this comment

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

Isn't such a breaking change an explicit violation of Rust's stability policy? Though I can't actually find where it's documented ATM, my understanding is that breaking changes are only permitted in the following cases:

  • The breakage is due to type inference
  • The breakage is required in order to fix a security issue

Copy link
Contributor

@joshlf joshlf Nov 12, 2024

Choose a reason for hiding this comment

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

As described in #3718 (comment), it should be simple to avoid this problem by introducing a new repr (in addition to the proposed #[repr(system)]) instead of changing the behavior of #[repr(C)].

Copy link
Member

@RalfJung RalfJung Nov 12, 2024

Choose a reason for hiding this comment

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

It's definitely in a gray area. One cold also argue that the existing repr(C) is simply wrong/unsound, and we have to fix it to satisfy its promise of providing type layout compatible with the current target's C ABI.

Copy link
Member

@programmerjake programmerjake Nov 12, 2024

Choose a reason for hiding this comment

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

iirc someone suggested deprecating repr(C) entirely and replacing it with repr(linear), repr(really_C_bikeshed), and other reprs as necessary.

1. Having a target-independent and stable representation of the data structure for storage or transmission.
2. FFI with C and C++ libraries compiled for the same target.
3. Interoperability with operating system APIs.

Today, `#[repr(C)]` is being used for all 3 scenarios because the user cannot create a `#[repr(C)]` struct with ambiguous layout between targets. However, this also means
that there exists some C layouts that cannot be specified using `#[repr(C)]`.

This RFC addresses use case 2 with `#[repr(C)]` and use case 3 with `#[repr(system)]`. For use case 1, people will have to seek alternative solutions such as `crABI` or
protobuf. However, it could be a footgun if people continue to use `#[repr(C)]` for use case 1.



# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

This RFC clarifies that:
- `repr(C)` must interoperate with the C compiler for the target.
- `repr(system)` must interoperate with the operating system APIs for the target.
- Similiar to Clang, `repr(C)` does not guarantee consistent layout between targets.

Alternatively, we can also create syntax that allows the user to specify exactly which semantic to use when packed structs transitively contains aligned fields.
For example, a new attribute: #[repr(align_override_packed(N))] that can be used when the behavior of the child overriding the parent alignment is desired.

#[repr(align(N))] #[repr(packed)] can be used together to get the opposite behavior, parent/outer alignment wins.

Explicitly specifying the pack/align semantic has the drawback of complicating FFI. For example, you might need two different definition files depending on the target.

Therefore, a stable layout across compilation target should be relegated as future work.




# Prior art
[prior-art]: #prior-art

Clang matches the Windows ABI for `x86_64-pc-windows-msvc` and matches the GCC ABI for `x86_64-pc-windows-gnu`.

MinGW always uses the GCC ABI.
Copy link
Member

@RalfJung RalfJung Oct 31, 2024

Choose a reason for hiding this comment

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

Is there prior art for a compiler that can lay out types both using the Windows ABI and the GCC ABI for code within a single target? If yes, how are they distinguishing the two? If no, why does Rust need this ability?

Copy link
Member

@programmerjake programmerjake Oct 31, 2024

Choose a reason for hiding this comment

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

gcc apparently supports that by using the ms_struct attribute

Copy link
Member

@RalfJung RalfJung Nov 1, 2024

Choose a reason for hiding this comment

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

So that would correspond tom in Rust

  • have repr(C) on win-gnu targets match non-win targets
  • have a separate window-only repr(MS) to ask for the msvc layout

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

For a more full parallel to extern "ABI", we should also support repr(GCC). Then repr(C) is a sort of alias to repr(GCC) or repr(MS) chosen by the target, like extern "C" is an alias (strongly newtyped) to "sysv64"/"win64" (etc).

Copy link

@CAD97 CAD97 Nov 1, 2024

Choose a reason for hiding this comment

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

clang appears to also implement [[gnu::ms_struct]] has an open PR implementing [[gnu::gcc_struct]]


We already have both `C` and `system` [calling conventions](https://doc.rust-lang.org/beta/nomicon/ffi.html#foreign-calling-conventions)
to support differing behavior on `x86_windows` and `x86_64_windows`.


This issue was introduced in the [original implementation](https://github.com/rust-lang/rust/issues/33158) of `#[repr(packed(N))]` and have since underwent extensive community discussions:
- [#[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs](https://github.com/rust-lang/rust/issues/100743)
- [repr(C) does not always match the current target's C toolchain (when that target is windows-msvc)](https://github.com/rust-lang/unsafe-code-guidelines/issues/521)
- [repr(C) is unsound on MSVC targets](https://github.com/rust-lang/rust/issues/81996)
- [E0587 error on packed and aligned structures from C](https://github.com/rust-lang/rust/issues/59154)
- [E0587 error on packed and aligned structures from C (bindgen)](https://github.com/rust-lang/rust-bindgen/issues/1538)
- [Support for both packed and aligned (in repr(C)](https://github.com/rust-lang/rust/issues/118018)
- [bindgen wanted features & bugfixes (Rust-for-Linux)](https://github.com/Rust-for-Linux/linux/issues/353)
- [packed type cannot transitively contain a #[repr(align)] type](https://github.com/rust-lang/rust-bindgen/issues/2179)
- [structure layout using __aligned__ attribute is incorrect](https://github.com/rust-lang/rust-bindgen/issues/867)


# Unresolved questions
[unresolved-questions]: #unresolved-questions

None for now.


# Future possibilities
[future-possibilities]: #future-possibilities

People intending for a stable struct layout consistent across targets would be directed to use `crABI`.