repr(C) on MSVC targets does not always match MSVC type layout when ZST are involved

[mahkoh]

Also see this summary below.

Consider

#![allow(dead_code)]

use std::mem;

#[no_mangle]
pub fn sizeof_empty_struct_1() -> usize {
    #[repr(C)]
    struct EmptyS1 {
        f: [i64; 0],
    }

    // Expected: 4
    // Actual: 0
    mem::size_of::<EmptyS1>()
}

#[no_mangle]
pub fn sizeof_empty_struct_2() -> usize {
    #[repr(C, align(8))]
    struct X {
        i: i32,
    }

    #[repr(C)]
    struct EmptyS2 {
        x: [X; 0],
    }

    // Expected: 8
    // Actual: 0
    mem::size_of::<EmptyS2>()
}

#[no_mangle]
pub fn sizeof_enum() -> usize {
    #[repr(C)]
    enum E {
        A = 1111111111111111111
    }

    // Expected: 4
    // Actual: 8
    mem::size_of::<E>()
}

#[no_mangle]
pub fn sizeof_empty_union_1() -> usize {
    #[repr(C)]
    union EmptyU1 {
        f: [i8; 0],
    }

    // Expected: 1
    // Actual: 0
    mem::size_of::<EmptyU1>()
}

#[no_mangle]
pub fn sizeof_empty_union_2() -> usize {
    #[repr(C)]
    union EmptyU2 {
        f: [i64; 0],
    }

    // Expected: 8
    // Actual: 0
    mem::size_of::<EmptyU2>()
}

and the corresponding MSVC output: https://godbolt.org/z/csv4qc

The behavior of MSVC is described here as far as it is known to me: https://github.com/mahkoh/repr-c/blob/a04e931b67eed500aea672587492bd7335ea549d/repc/impl/src/builder/msvc.rs#L215-L236

[jyn514]

@mahkoh can you reproduce this without no_mangle? no_mangle should really require unsafe, it can cause unsoundness if it overlaps with another linker symbol.

[mahkoh]

@jyn514 Yes

[mahkoh]

repr(C) has served two purposes:

• A representation with a know layout algorithm which is the same across all targets
• A representation that is compatible with C types

The first purpose is advertised both in the reference and in stdlib code e.g. in Layout. It is probably used in many other places.

The second purpose is also advertised in the reference.

However, these purposes are not compatible as shown above.

[jonas-schievink]

The layout algorithm is not the same across all targets, it is always supposed to be whatever the C ABI mandates on that particular target

[jonas-schievink]

Does this reproduce with clang?

[mahkoh]

The layout algorithm is not the same across all targets, it is always supposed to be whatever the C ABI mandates on that particular target

The layout algorithms used by the C compilers are not the same. But repr(C) is advertised with a specific layout algorithm that is the same across all targets. Namely in these places

• https://doc.rust-lang.org/reference/type-layout.html#reprc-structs
• https://doc.rust-lang.org/stable/std/alloc/struct.Layout.html#method.extend

Does this reproduce with clang?

Clang contains many bugs in their MSVC-compatible layout algorithm. It should not be used as a reference:

• https://bugs.llvm.org/show_bug.cgi?id=48787
• https://bugs.llvm.org/show_bug.cgi?id=48777
• https://bugs.llvm.org/show_bug.cgi?id=48776
• https://bugs.llvm.org/show_bug.cgi?id=48835
• https://bugs.llvm.org/show_bug.cgi?id=48842
• https://bugs.llvm.org/show_bug.cgi?id=48849
• https://bugs.llvm.org/show_bug.cgi?id=48850
• https://bugs.llvm.org/show_bug.cgi?id=48875

The output of clang is incompatible with both MSVC and rustc: https://github.com/llvm/llvm-project/blob/661f9e2a92302b1c7140528423fdbfc133a68b41/clang/lib/AST/RecordLayoutBuilder.cpp#L3076-L3087

[rylev]

Let's make sure the windows notification group is aware of this:

@rustbot ping windows

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra

[rylev]

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.