LINUX.ORG.RU

Опубликован способ обхода borrow checker в Rust

 


3

10

Jakub Kądziołka опубликовал proof-of-concept, показывающий непосредственные проблемы, связанные с ошибкой в проекте компилятора Rust, которую разработчики безуспешно пытаются решить уже на протяжение четырех лет.

Пример, разработанный Jakub, позволяет обойти Borrow Checker посредством очень простого трюка:

fn main() {
    let boom = fake_static::make_static(&vec![0; 1<<20]);
    println!("{:?}", boom);
}

Разработчик просит не использовать этот обход в Production, так как его целью было только привлечь внимание к проблеме, игнорируемой разработчиками Rust.

>>> Подробности

anonymous

Проверено: jollheef ()

посредством очень простого трюка

4.2

Реальный код:

static UNIT: &'static &'static () = &&();

fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'a, T>(x: &'a T) -> &'static T {
    let f: fn(&'static &'a (), &'a T) -> &'static T = foo;
    f(UNIT, x)
}
RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

И эти люди еще жалуются, что perl выглядит как нечитаемое месиво.

ncrmnt ★★★★★ ()

Растом они похоронили Фурефокс, пусть закапывают свое поделие.

novikovag ()
Ответ на: комментарий от ncrmnt

Ну так это синтетика. Самый минимальный, рабочий код.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

``` (_: &'a &'b (), v: &'b T) -> &'a T ``` Прелестно.

anonymous ()

А кто в здравом уме в проде будет обходить БЧ?

anonymous ()
Ответ на: комментарий от anonymous

А кто в здравом уме в проде будет обходить БЧ?

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

tailgunner ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Я его не изучал и не знаю где он может пригодиться.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Попробую еще раз

(_: &'a &'b (), v: &'b T) -> &'a T

Прелестно. Тип-функция «забывания». Странно, что сразу не срабатывает foo, прячет за еще одной подобной конструкцией «забывания». Кажись, совсем дырявый borrow-checker, колосс на глинаных ногах.

anonymous ()

игнорируемой разработчиками Rust

Просто этот баг не оскорбляет чувств никаких меньшинств, вот на него и не обращают внимания.

xaizek ★★★★★ ()
Ответ на: комментарий от anonymous

Странно, что сразу не срабатывает foo

Не странно. Суть проблемы в том, что сабтайпинг типа функции нарушает ограничения на лайфтаймы ('b: 'a).

quantum-troll ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Боже правый, на этом птичьем языке кто-то хочет добровольно писать?

Im_not_a_robot ★★★★ ()
Ответ на: комментарий от quantum-troll

Забавно. Т.е. чуваки запилили всё это без какого-либо доказательства корректности? Я краем глаза слежу за проектом добавления линейных типов в хацкелл, там вроде такого быть не должно ввиду отсутствия сабтайпинга.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от quantum-troll

сабтайпинг типа функции нарушает ограничения на лайфтаймы

Интересно, как реализован сабтайпинг типов с лафтаймами? Судя по возможности «забывателя», никак.

anonymous ()
Ответ на: комментарий от hateyoufeel

Линейные типы без ссылок лайтаймов (и соответственно, сабтайпинга) не требуют.

quantum-troll ★★★★★ ()

ЛОР по-прежнему ломается на растокоде (впрочем тут кто угодно сломается).

bread ()
Ответ на: комментарий от anonymous

Без учёта ограничений он реализован корректно: контрвариативно по аргументам, ковариативно по возвращаемому значению.

Судя по возможности «забывателя»

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

forall 'a, 'b, T; &'a &'b (), &'b T -> &'a T where 'b <: 'a
'a = 'static
-----
Ошибка, 'b <: 'static выполняется лишь в случае, когда 'b = 'static


Однако сабтайпинг без ограничений приводит к фейлу:

&'static &'static <: &'static &'b
-----
fn(&'static &'b) <: fn(&'static &'static)

quantum-troll ★★★★★ ()
Последнее исправление: quantum-troll (всего исправлений: 2)
Ответ на: комментарий от RazrFalcon

Я правильно понимаю, что в Rust полно «багов» которые приводят к UB и прочему, но евагелисты все равно говорят о #nogc #memorysafety?

shkolnick-kun ★★★★ ()

Баг, ну прямо новости достойно. Срочно удалить раст из репов.

Я даже больше скажу, давно тоже самое с помощью unsafe делается

vertexua ★★★☆☆ ()
Ответ на: комментарий от vertexua

Мякотка в том, что это сделано без unsafe, соответственно есть ненулевая вероятность появления «дыр» в «безопасном» коде…

shkolnick-kun ★★★★ ()
Последнее исправление: shkolnick-kun (всего исправлений: 2)
Ответ на: комментарий от shkolnick-kun

Ненулевая вероятность была всегда, потому что это код, а в коде бывают баги

vertexua ★★★☆☆ ()
Ответ на: комментарий от RazrFalcon

В данном случае, это сработает даже в redox, которая вроде не зависит от libc…

shkolnick-kun ★★★★ ()
Ответ на: комментарий от shkolnick-kun

Фишка в том, что все эти «баги» почти нереально получить в реальном коде. Ну и их в итоге исправят, в отличии от.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Зато, когда они будут внесены NSA в какую-нибудь tls.rs, их будет нереально найти.

shkolnick-kun ★★★★ ()
Ответ на: комментарий от shkolnick-kun

До тех пор, пока компилятор не пофиксят. В этом и прелесть.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

По такой логике и C — memory safe, до тех пор, пока clang static analyzer не пофиксят.

anonymous ()
Ответ на: комментарий от RazrFalcon

Тогда почему ты у него еще не был? «пока компилятор не пофиксят» — это ведь твои слова, а не мои.

anonymous ()
Ответ на: комментарий от RazrFalcon

Помнится, в очень старой книжке то ли про C, то ли про C++ (такая голубенькая, не очень толстая, ну вы поняли; изучал по ней язык в 80-х, сидя в пионерлагере в бараке на кровати), рядом с обсуждением о вреде злоупотребления дикими «выразительными» конструкциями была карикатура вроде этой, только в облачке слева была сишная абракадабра (что-то типа «*pch[!x]&&...»).

dimgel ★★ ()

Что получается, когда разрабатывают языки без разработки соответствующих формальных систем.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.