Кстати, а вы знали, что для нульарных и одноарных кортежей в Rust есть альтернативный синтаксис — с использованием фигурных скобок?

assert!(() == {});
assert!((42) == {42});

#prog #rust #моё

Тем временем в комментариях вспомнили weird-exprs.rs — "Just a grab bag of stuff that you wouldn't want to actually write.". Если быть точнее, то функцию special_characters. Выглядит она так:

fn special_characters() {
let val = !((|(..):(_,_),__@_|__)((&*"\\",'🤔')/**/,{})=={&[..=..][..];})//
;
assert!(!val);
}

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

let val = !((|(..):(_,_),__@_|__)((&*"\\",'🤔'),{})=={&[..=..][..];});

Справа отрицание некоего выражения. Вынесем его в отдельную переменную и заодно уберём наружные скобки:

let tmp = (|(..):(_,_),__@_|__)((&*"\\",'🤔'),{})=={&[..=..][..];};
let val = !tmp;

Хм, определение tmp всё ещё выглядит сложноватым... Может, вызвать rustfmt?

let tmp = (|(..): (_, _), __ @ _| __)((&*"\\", '🤔'), {}) == {
&[..= ..][..];
};

Сильно проще не сделало, но зато теперь видно, что корень дерева выражений — это операция равенства. Посмотрим, что тут справа:

{
&[..= ..][..];
}

Хм, что тут у нас? У нас тут массив размера 1, в котором лежит выражение ..= .. (первый рендж, кстати, биндится первым и потому выражение в целом имеет тип RangeToInclusive<RangeFull>), который индексируется RangeFull, что работает за счёт deref coercion к соответствующему типу слайса, на полученный слайс берётся ссылка...

Но всё это можно было бы и не рассматривать, поскольку строчка оканчивается точкой с запятой, а потому выражение, каким бы оно ни было, отбрасывается, и в целом получается statement. А блок, который оканчивается statement-ом, как известно, возвращает в Rust ().

Итак, с правой часть равенства разобрались. А что же с левой?

(|(..): (_, _), __ @ _| __)((&*"\\", '🤔'), {})

Здесь у нас после открывающей скобки идёт |. Так как бинарное выражение с этого оператора начинаться не может, это начала определения замыкания. После заключённого в скобке замыкания идёт её вызов с двумя аргументами. Посмотрим на литерал замыкания поподробнее:

|(..): (_, _), __ @ _| __

Между чёрточками тут два аргумента, разделённых запятой. И тут на полной используется тот факт, что на месте аргументов можно использовать не только идентификаторы, но и произвольные (но которые тайпчекаются, разумеется) паттерны. Вот первый аргумент:

(..): (_, _)

За аргументами в замыканиях может опционально следовать двоеточие и тип аргумента, причём, в отличие от типов в обычных функциях, он не обязательно должен быть выписан полностью. (_, _) тут означает двухместный кортеж с типами, которые нужно вывести компилятору.

(..) же — это паттерн, который матчится с кортежем с произвольным количеством полей. Кстати, с кортежными структурами и кортежными вариантами перечислений этот паттерн тоже работает — достаточно добавить имя. Например, вот этот код тайпчекается:

struct ManyFields(i32, String, char, u8, i32);

fn foo(mf: ManyFields) {
    let ManyFields(..) = mf;
}

Можно даже сматчить только поля из части кортежа:

fn ends(mf: &ManyFields) -> (i32, i32) {
match mf {
&ManyFields(start, .., end) => (start, end),
}
}

Впрочем, я отвлёкся.

Второй аргумент — это __ @ _. Как всегда в @-биндингах (ладно, ладно, at-биндингах), справа от @ находится паттерн — в данном случае _, который матчится абсолютно со всем — а слева от @ находится имя, которое привязывается к этому значению, __. Безусловно, идентификатор выглядит странно, но это валидное имя в Rust.

Ещё раз взглянем на замыкание целиком:

|(..): (_, _), __ @ _| __

Тело замыкания состоит из единственного идентификатора __. Иными словами, замыкание просто возвращает свой второй аргумент. С тем же успехом его можно было бы написать так:

|_, second| second

(или, если быть точнее и сохранить тот факт, что первый аргумент является парой, |_: (_, _), second| second).

Окей, с замыканием мы разобрались. Но чтобы понять, что же оно в итоге возвращает, нам нужно посмотреть на то, с какими аргументами оно вызывается:

(замыкание...)((&*"\\", '🤔'), {})

Первый аргумент — это пара (как и ожидается) из &str и char. Фрагмент &*"\\" валиден за счёт того, что строковой литерал имеет тип &'static str и, соответственно, его можно разыменовать (и взять ссылку от результата). Кстати, тут используется синтаксис для escaping-а, поэтому содержимое строки — это единственный символ \. А вот второй аргумент — это пустой блок. В Rust он вычисляется в (). С учётом того, что замыкание просто возвращает свой второй аргумент, получаем, что часть слева от оператора равенства просто возвращает ().

Теперь сложим вместе всё изложенное выше. Переменной val присваивается отрицание от сравнивания () и (). Так как unit всегда равен самому себе, в val записывается значение false. Строчкой ниже в функции вызывается assert!(!val), который ожидаемо проходит.

Как видите, тут нет абсолютно ничего сложного. 👌

#prog #rust #itsec

blog.rust-lang.org/2022/01/20/cve-2022-21658.html

> Rust 1.0.0 through Rust 1.58.0 is affected by this vulnerability.

Oof

#prog #rust

Вафель двигает Rust вперёд ✊🎉

#prog #meme

Сделал мем по мотивам https://t.iss.one/oleg_log/5319

#prog #rust

Does the Bronze Garbage Collector Make Rust Easier to Use? A Controlled Experiment

Разумеется, я не мог пройти мимо статьи с подобным еретическим громким заявлением. Авторы разработали сборщик мусора, решив при помощи stack maps от LLVM проблемы идентификации корней. Как сказано в абстракте:

> We found that for a task that required managing complex aliasing, Bronze users were more likely to complete the task in the time available, and those who did so required only about a third as much time (4 hours vs. 12 hours). We found no significant difference in total time, even though Bronze users re-did the task without Bronze afterward.

Однако меня заинтересовал сам сборщик мусора. В тексте я натолкнулся на упоминание того, что в эксперименте использовалась версия, которая фактически сборку мусора не проводила. Меня это насторожило. Я пошёл смотреть исходники и увидел issue (со ссылкой на URLO) о том, что bronze позволяет иметь две мутабельные ссылки на одно и то же значение одновременно. Что вообще-то UB. Таким образом, авторы фактически проверяли не "Rust со сборщиком мусора", а "Rust с выключенным borrow checker", что фактически ставит под сомнение результаты эксперимента. Авторы при этом ничего страшного в этом не видят. Более того, в треде отметили, что авторы скопировали часть кода из rust-gc от Manish Earth, при том,что bronze имел лицензию BSD, а rust-gc — Mozilla Public License 2.0, копилефтную лицензию.

Короче, дурная история

#prog #article

The Discovery of Apache ZooKeeper’s Poison Packet — статья от 2015 года об экзотическом баге, который связал воедино баги в ZooKeeper и ядре Linux. Да, серьёзно.

(thanks @oleg_log)

Какой же всё-таки у Instagram отвратительный интерфейс

#rust

В сорцах rustc банят числа.

Кстати, включил

Я нашёл ICE [internal compiler error], которой можно добиться за 29 символов программы 🙂

Правда ICE чисто технически в форматтере, но всё же.

macro_rules! a{()=>{A<'a,>};}

Когда я плакал, что не понимаю атомики (я и сейчас плачу, ахаха), мне посоветовали посмотреть несколько докладов, включая этот (в двух частях):

— CppCon 2014: Herb Sutter "Lock-Free Programming (or, Juggling Razor Blades), Part I"
— CppCon 2014: Herb Sutter "Lock-Free Programming (or, Juggling Razor Blades), Part II"

Доклад очень интересный, рекомендую!!

В начале рассказывается про атомики в целом, а потом приводятся примеры того, как их можно использовать. В самом конце убийственный пример из реальной жизни, приведу цитату: «And for better performance we'll do more heap allocations».

Доклад в большей степени ориентирован на тех кто не очень хорошо знает что такое атомики, но и для тех кто знает не плохо, думаю тоже будет полезно.

Посмотрел тут свои гисты от и до, и... Ну, неудивительно, что я Rust простым называю, я его, выходит, учу уже четыре года.

— Ты когда-нибудь перестанешь упоминать Rust по поводу и без?
— println!("Нет");