#prog #cpp

Действительно, выразительный.

https://twitter.com/Nekrolm/status/1326175405397651457

#prog #rust #compiler #article

Восхитительная длинная статья от Крендель-молота про написание компилятора brainfuck под x86_64, ARM64, WASM и LLVM IR.

github.com/pretzelhammer/rust-blog/blob/master/posts/too-many-brainfuck-compilers.md

#prog #rust tip: спецификатор фрагмента vis в макросах сопоставляется с описанием видимости определения, в том числе и пустым.

К примеру, следующий код компилируется:

macro_rules! accept_with_vis {
    ($vis:vis struct $name:ident;) => {}
}

accept_with_vis!{struct Foo;}

macro_rules! accept_with_vis {
    ($vis:vis struct $name:ident;) => {}
}

accept_with_vis!{struct Foo;}

...Но не когда нужно сопоставиться только с спецификатором видимости (thanks @sajitar, который и заполнил issue). Вот этот код не компилируется:

macro_rules! accept_just_vis {
    ($vis:vis) => {}
}

accept_just_vis!{}

#prog #rust #моё

Как многие из вас знают (а если не знаете — узнаете сейчас), в Rust нельзя перемещать (move) поля из значения типа, имеющего нетривиальную реализацию Drop. В частности, значение типа, реализующего Drop, нельзя деструктурировать. Однако надо отметить, что если тип поля реализует Copy, то к этому полю можно обратиться, в том числе и пре деструктуризации, при этом значение этого поля скопируется. Проиллюстрирую только что сказанное:

struct NonCopy;

struct Dropping<T>(T, NonCopy);

impl<T> Drop for Dropping<T> {
   fn drop(&mut self) {
       println!("dropped");
   }
}

fn main() {
   // ⬇️ если раскомментировать эту строку, то программа не скомпилируется с E0509
   // let Dropping(_non_copy, _) = Dropping(NonCopy, NonCopy);

   // А вот это — компилируется и печатает "dropped".
   // Обратите внимание, паттерн `_`  *не* перемещает значение.
   let Dropping(_x, _) = Dropping(0_u32, NonCopy);
}

Где это может выстрелить? При написании биндингов к сишным либам. Одна их техник обеспечения инкапсуляции в C — это определение структуры в заголовочном файле без определения её полей. Это позволяет получить доступ к полям структуры только там, где дано её определение, а внешний код может обращаться к ней лишь по указателю. И указатель — это Copy-тип, да.

Пусть это выглядит примерно так:

extern "C" {
   // extern types ещё не стабилизированы, так что
   // в реальной библиотеке, скорее всего, будут использовать *mut std::ffi::c_void


    type Some_C_Struct;
    fn c_lib_release_resources(arg: *mut Some_C_Struct);
}

struct Handle(*mut Some_C_Struct);

impl Drop for Handle {
    fn drop(&mut self) {
        unsafe { c_lib_release_resources(self.0) }
    }
}

Что произойдёт, если мы попытаемся деструктурировать Handle? Скажем, нам зачем-то потребовалась реализация метода leak:

impl Handle {
    fn leak(self) -> *mut Some_C_Struct {
        // Здесь мы разбираем значение, но так как указатель — Copy-тип,
        // имя ptr привязывается к копии значения, перемещения не происходит.
        let Handle(ptr) = self; // <-- после этой точки с запятой кончается время жизни self, и вызывается деструктор
        // Ура, у нас на руках невалидный указатель!
        ptr
    }
}

Что можно с этим сделать? Использовать ManuallyDrop. Этот тип предотвращает вызов деструктора (а также деструктуризацию, поскольку у него приватные поля), но при этом не предотвращает доступ к полям значения внутри (через Deref). Возникает вопрос, почему не использовать std::mem::forget? В принципе, в документации подробно расписано, но если коротко, то std::mem::forget значительно сложнее корректно использовать.

Сишный код в двух словах:

Бе ды
с
вла дением

Прошу прощения, в предыдущем опросе один диапазон возрастов просто не был представлен

Если вы не можете, потому что у вас лапки — значит, вы котик.

#prog #rust

PR, добавляющий поддержку кастомных аллокаторов для Vec 🎉. Первый шаг на пути к стандартным коллекциям с полностью настраиваемым аллокатором.

Интересным является тот факт, что тип остался тот же, но на stable указать аллокатор пока нельзя. Это стало возможным благодаря этому PR, который позволил вешать аннотации стабильности на ти́повые параметры.

#prog #abnormalprogramming #retroit

К-А-Й-Ф

Гайд по тому, как DOS записать на винил и грузиться с него.

#prog #meme #rust

@DogeShibu всё правильно говорит

А у кого день рождения? У @ihatereality день рождения!

С днём рождения, наше любимое умное асексуальное кондитерское изделие!

#prog

Пока гром не грянет...

Go SMS Pro, популярный мессенджер на Андроид, при пересылке картинок или файлов между пользователями закачивает их на свой сервер, чтобы ссылка была доступна для просмотра даже без приложения. Но нумерация этих файлов идёт по порядку, и при желании можно перебором просматривать чужие файлы, которые могут содержать конфиденциальную информацию. Попытки связаться с разработчиками не увенчались успехом, проблема остаётся неисправленной  

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/go-sms-pro-vulnerable-to-media-file-theft/

На свидании выяснилось, что кандидат завёл интрижку с Rust

"Тут как бы сишные нестандартизированные API, я бы назвал это pain driven developement"

#трудовыебудни

Завтра (технически сегодня) будет пост про Rust

#prog #abnormalprogramming

"Змейка" на клавиатуре с подсветкой.

Видеодемонстрация
Статья с разбором реализации
Перевод на Хабре