- [ ] Умеет писать unsafe код и безопасные обёртки для него. - [ ] Понимает причины UB и знает, как его не допустить. (откуда взялось, что значит и как может нанести вред работе программы) - [ ] для автора - проверка ОРа квизами, включая примеры кода. - [ ] Умеет проектировать безопасный интерфейс для unsafe кода. - [ ] Знает best practice для написания unsafe кода. - [ ] Можно использовать примеры из third party крейтов. - [ ] Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub - [ ] Рассказать про причины ub - [ ] Рассказать, чем является unsafe, ответственность на программисте, про ub (НЕ является избавлением от borrow checker) - [ ] Рассказать про применение unsafe (взаимодействие с С, оптимизация (вспомнить небезопасную либу для бэкенда: rocket или actix), написание основы/базы языка) - [ ] Определении функции unsafe если соблюдение инвариантов висит на пользователе (при написании такой функции смотреть - является ли сам интерфейс функции safe) - [ ] примеры из third party - [ ] Рассказать про бест практис при написании unsafe: - [ ] Лучший unsafe - отсутствующий unsafe - [ ] Уменьшение зоны unsafe (легче найти баг + проще просчитать ub) - [ ] Safety - [ ] SAFETY - [ ] assert_unsafe_precondition! - [ ] ... - [ ] Практика - [ ] Лайфтаймы как помошники при взаимодействии с c abi - [ ] Drop Почему unsafe внутри unsafe fn: фн показывает, что инварианты должен соблюдать пользователь функции ансейф блок же показывает скоуп, где нужно искать баги (где они и будут тк анйсейф операция) подводный камень: при ансейф баг может возникать в любом из блоков анйсефа, даже если он возникает в другом месте ub: из-за различий архитектру цп и ос и для оптимизаций еслм возникает баг, значит неправильно реализованы инварианты в одном из unsafe блоков с которым взаимодействовали (даже в совершенно другом месте) Возможно рассказать еще про это все? - pointers - nonnull - phantomdata (инвариантность/ковариантность и тд) - unsafecell - send/sync + unsafe trait markers (мб практический пример: написание собстенного mutex) - unsafe traits - При описании бест практис про Safety, привести пример, почему нужно (а еще потому, что при изменении логики функции самим тоже нужно следить, какие инварианты висят за пользователем) Практика: подумайте над тем, какие инварианты тут должны быть соблюдены и какие из них не соблюдены. или пропробовать найти несоблюденный инвариант и "взломать" программу?) допустим, нам нужно дя создания сокета узнать, можем ли мы использовать tcp/udp/icmp/etc, для этого используем сискол WSAEnumProtocolsA **Начать с проблемы, когда компилятор не может гарантировать безопасность по памяти (но без этого невозможно написать программу), возможно из ub** **Рассказать про причины ub** Именно для этого и было создано **Рассказать, чем является unsafe, ответственность на программисте, про ub (НЕ является избавлением от borrow checker)** **Рассказать про применение unsafe (взаимодействие с С, оптимизация (вспомнить небезопасную либу для бэкенда: rocket или actix), написание основы/базы языка)** - [ ] Определении функции unsafe если соблюдение инвариантов висит на пользователе (при написании такой функции смотреть - является ли сам интерфейс функции safe) - [ ] примеры из third party - [ ] Рассказать про бест практис при написании unsafe: - [ ] Лучший unsafe - отсутствующий unsafe - [ ] Уменьшение зоны unsafe (легче найти баг + проще просчитать ub) - [ ] Safety - [ ] SAFETY - [ ] assert_unsafe_precondition! - [ ] ... - [ ] Практика - [ ] Лайфтаймы как помошники при взаимодействии с c abi - [ ] Drop