`offset_of_slice` exposes whether a custom DST has a private slice field

[kpreid]

The following program compiles:

#![feature(offset_of_slice)]

mod foo {
    pub struct Inner {
        foo: u8,
        tail: [u8],
        // tail: dyn core::fmt::Debug,
    }
    pub struct Outer {
        pub dst: Inner,
    }
}

fn main() {
    assert_eq!(core::mem::offset_of!(foo::Outer, dst), 0);
}

It does not compile if the type of tail is changed to a dyn type. I believe neither version should compile, because tail is a private field, and therefore information about its type should not leak to places where it is not visible.

rustc version: 1.87.0-nightly (2025-03-09 3ea711f)

@rustbot label F-offset_of_slice C-bug

[asquared31415]

I would expect both of those cases to compile, as the user is not attempting to observe anything about Inner at all, only the offset of the field dst within Outer.

[kpreid]

I’m sorry, I should have given more context for the issue. The entire point of the base restriction which offset_of_slice relaxes for slices is that it is impossible to statically obtain the offset of dyn Trait, because its alignment and therefore its required offset is dynamic. Consider this program:

use std::sync::atomic::*;
use std::fmt::Debug;
use std::mem::align_of_val;

#[repr(C)]
pub struct Dst<T: ?Sized> {
    head: u8,
    tail: T,
}

fn dynamic_offset_of_tail<T: ?Sized>(value: &Dst<T>) -> usize {
    (&raw const value.tail).addr() - (&raw const *value).addr()
}

fn main() {
    let dst1: &Dst<dyn Debug> = &Dst { head: 0, tail: AtomicU8::new(0) };
    let dst8: &Dst<dyn Debug> = &Dst { head: 0, tail: AtomicU64::new(0) };

    assert_eq!(dynamic_offset_of_tail(dst1), 1);
    assert_eq!(dynamic_offset_of_tail(dst8), 8);
    assert_eq!(align_of_val(dst1), 1);
    assert_eq!(align_of_val(dst8), 8);
}

Two values of identical type, Dst<dyn Debug>, have different offsets for their fields, and different alignments for the entire value. Therefore, in the original program, if foo::Inner's field is made to be dyn Debug, it is impossible for offset_of!(foo::Outer, dst) to succeed — there is no one correct value for it to return (in the general case where Outer may also have other fields). Therefore, the fact that it does succeed when tail is a slice leaks implementation details.

[asquared31415]

Ah right, if Outer had a head: u8 then the offset of dst inside Outer would change depending on the alignment of Inner, which is possibly dynamic. This is quite tricky indeed :c

[zachs18]

I think "because tail is a private field, and therefore information about its type should not leak to places where it is not visible" might not necessarily be true (even ignoring feature(offset_of_slice)), since users can observe that casts between *const [T] and *const Outer compile, so they know that Outer has the same pointer metadata as slices, and currently the only way for that to be the case is for it to have a slice tail.

[kpreid]

Personally, I would argue it’s a flaw in the language that that is already observable, and there shouldn’t be even more occurrences of the same flaw. But I understand that’s much more debatable than revealing not-previously-revealed information.