Блог*

Но сначала немного о том, как это деструктор должен выглядеть. С одной стороны, в нём должен быть код для дропа конкретного типа. С другой стороны, он должен принимать на вход стёртые аргументы. Кажущеюся противоречие разрешается за счёт двух вещей: лямбды без захватов могут быть приведены к функциональным указателям и захват типа не ведёт к захвату значения:

type Destructor = unsafe fn(*mut (), ErasedVtable);

fn make_drop_fn<T>() -> Destructor {
    |data, vtable| unsafe {
        let dyn_ptr: *mut ??? =
            std::ptr::from_raw_parts_mut(data, std::mem::transmute(vtable));
        drop(Box::from_raw(dyn_ptr))
    }
}

Возникает небольшой вопрос, что подставить вместо ???. Это не может быть dyn FnMut(&mut T), так как нам ещё нужно как-то добавить деструктор. Что ж, сделаем под это тип:

#[repr(C)]
struct WithDrop<T: ?Sized> {
    destructor: Destructor,
    data: T,
}

В make_drop_fn вместо ??? подставим WithDrop<dyn FnMut(&mut T)>. Очевидно, конструктор ErasedDyn придётся немного поменять:

impl ErasedDyn {
    fn new<T, F>(f: F) -> Self
    where
        T: 'static,
        F: FnMut(&mut T) + 'static,
    {
        let with_drop = WithDrop {
            destructor: make_drop_fn::<T>(),
            data: f,
        };
        let boxed = Box::new(with_drop) as Box<WithDrop<dyn FnMut(&mut T)>>;
        let (data, vtable) = Box::into_raw(boxed).to_raw_parts();
        Self {
            data,
            vtable: unsafe { std::mem::transmute(vtable) },
        }
    }
}

Ну и, раз уж мы сделали деструктор, то, очевидно, надо сделать надлежащую реализацию Drop:

impl Drop for ErasedDyn {
    fn drop(&mut self) {
        unsafe {
            let destructor = self.data.cast::<Destructor>().read();
            destructor(self.data, self.vtable);
        }
    }
}

Каст из data в указатель на Destructor валиден за счёт того, что WithDrop имеет фиксированную раскладку в памяти — #[repr(C)] — и адрес первого поля совпадает с адресом структуры в целом. Окей, с дропом мы разобрались, но теперь нам нужно поменять метод для даункаста. Теперь нам надо каким-то образом получить из указателя на WithDrop<dyn FnMut(&mut T)> указатель на data. Кажется, достаточно просто сместить указатель на размер Destructor?..

impl ErasedDyn {
    unsafe fn downcast_mut_unchecked<T: 'static>(&mut self) -> &mut dyn FnMut(&mut T) {
        let data_ptr = self
            .data
            .byte_offset(std::mem::size_of::<Destructor>() as isize);
        let vtable = std::mem::transmute(self.vtable);
        &mut *std::ptr::from_raw_parts_mut(data_ptr, vtable)
    }
}

А вот и нет.

Именно, этот unsound код полагается на то, что data располагается в памяти сразу после destructor, без промежутков. И это абсолютно необоснованное предположение! Именно, unsized coercion добавляет vtable к указателям на данные, но, разумеется, никак не трогает данные за указателем. Раскладка в памяти данных за указателем зависит от исходного типа, из которого произошло unsized coercion — и конкретно в случае WithData тип поля data вполне мог иметь выравнивание большее, чем у Destructor! Как следствие, между destructor и data может быть паддинг, и, как несложно понять, подсчитать его статически после стирания типов нельзя.

Покажу наглядно, как ломается текущий подход:

fn main() {
    #[repr(align(16))]
    struct OverAligned(i32);

    let mut map = CallbackMap::default();
    let multiplier = OverAligned(7);
    // захватываем multiplier целиком, а не только поле
    let f = move |x: &mut i32| *x *= { &multiplier }.0;
    map.insert(f);
    let mut x = 6;
    map.get().unwrap()(&mut x);
    assert_eq!(x, 42);
}

Неправильная реализация downcast_mut выдаёт указатель куда-то в паддинг, в неинициализированные данные. Попытка их прочитать приводит к неопределённому поведению. На практике это означает, что ассерт у вас почти наверняка выстрелит (а в дебажной сборке — может и свалиться с паникой из-за переполнения при умножении). Если запустить этот пример в miri, то он выдаёт ошибку на момент создания ссылки — некорректное выравнивание.

❤3👍3

650 viewsedited 01:08