#prog #rust #article
Статья об особенностях синтаксиса Rust. Не без огрехов: некоторые аргументы откровенно притянуты за уши.
Статья об особенностях синтаксиса Rust. Не без огрехов: некоторые аргументы откровенно притянуты за уши.
Хабр
Так ли токсичен синтаксис Rust?
fn main() { println!("Hello, Rust!"); println!("... Goodbye!"); } Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом...
Forwarded from oleg_log (Oleg Kovalov)
Вы ведь знаете, что в го надо аккуратно с переменными из for-range обращаться, да?
Наверное каждый хоть раз обжигался о
или что-то похожее, где "захватывается" значение в кложуре. Есть даже пропозал, что давайте от этого уйдём (в го2, когдатотам) https://github.com/golang/go/issues/20733
Там забавный комент добавили, может слышали, Let's Encrypt недавно откатили 3М+ сертификатов. Угадайте из-за чего)))
https://github.com/letsencrypt/boulder/pull/4690/files#diff-d02067a9f9a2bed1110fd4e98641c2effcf5d1d5f18461e35d6ac1535f6e2c21L1411-R1414
Наверное каждый хоть раз обжигался о
for k, v := range foo {
go run(k,v)
}или что-то похожее, где "захватывается" значение в кложуре. Есть даже пропозал, что давайте от этого уйдём (в го2, когдатотам) https://github.com/golang/go/issues/20733
Там забавный комент добавили, может слышали, Let's Encrypt недавно откатили 3М+ сертификатов. Угадайте из-за чего)))
https://github.com/letsencrypt/boulder/pull/4690/files#diff-d02067a9f9a2bed1110fd4e98641c2effcf5d1d5f18461e35d6ac1535f6e2c21L1411-R1414
#prog #go
Несколько более подробно про инцидент. Это к вопросу о том, чем плох Go и почему мутабельность и разделяемость плохо сочетаются.
Суть ошибки состоит в том, что в неправильном коде переменная цикла захватывалась по указателю, то есть та самая переменная, которая меняется на каждой итерации. Это привело к тому, что позднее вместо вызова проверки для каждого из N элементов списка она вызывалась N раз для одного и того же элемента. И это известная ловушка.
Неприятной особенностью этого паттерна ошибки является то, что переменная может быть захвачена по указателю даже в том случае, если от неё не берётся явно адрес — можно вызвать на значении метод, принимающий значение по указателю, и это синтаксически неотличимо от вызова метода, принимающего значение по, собственно, значению. Также можно нарезать слайс, и синтаксически это не выглядит как взятие указателя, хотя и является семантически.
Несколько более подробно про инцидент. Это к вопросу о том, чем плох Go и почему мутабельность и разделяемость плохо сочетаются.
Суть ошибки состоит в том, что в неправильном коде переменная цикла захватывалась по указателю, то есть та самая переменная, которая меняется на каждой итерации. Это привело к тому, что позднее вместо вызова проверки для каждого из N элементов списка она вызывалась N раз для одного и того же элемента. И это известная ловушка.
Неприятной особенностью этого паттерна ошибки является то, что переменная может быть захвачена по указателю даже в том случае, если от неё не берётся явно адрес — можно вызвать на значении метод, принимающий значение по указателю, и это синтаксически неотличимо от вызова метода, принимающего значение по, собственно, значению. Также можно нарезать слайс, и синтаксически это не выглядит как взятие указателя, хотя и является семантически.
The Register
Let's Encrypt? Let's revoke 3 million HTTPS certificates on Wednesday, more like: Check code loop blunder strikes
Tons of TLS certs need to be tossed immediately after Go snafu
Forwarded from Generative Anton
Есть забавная традиция называть проекты/библиотеки именами различных мифических существ и божеств. И у меня давно лежала идея хелпера по подбору таких названий, но реализовал только сейчас.
Я напарсил самый большой список названий божеств из 43 пантеонов, что дало 4096 уникальных имён (и 9000 если считать ещё все алиасы). Ну а чтобы избежать коллизий, проект на лету ищет эти имена в названиях репозиториев на Гитхабе и показывает топ-результаты.
Из интересной инженерии: проект на Svelte, чуть позже опубликую сорцы. И внутри есть база на 1Мб сырого json'a, которая затаскивается в общий бандл приложения и ужимается до 150кб. И из-за этого хака всё успешно хостится как статика на Digital Ocean'e за 0.00$ в месяц. Дизайн тоже корявенько делал я. И запросы к Гитхабу — клиентские, лимиты запросов — только клиентские. Легчайшая поддержка.
Из того, что осталось доделать: стили на небольших экранах немного едут, но не критично.
Во славу NJARANA, австралийского бога сна хороших собак.
https://newprojectname.dev
Я напарсил самый большой список названий божеств из 43 пантеонов, что дало 4096 уникальных имён (и 9000 если считать ещё все алиасы). Ну а чтобы избежать коллизий, проект на лету ищет эти имена в названиях репозиториев на Гитхабе и показывает топ-результаты.
Из интересной инженерии: проект на Svelte, чуть позже опубликую сорцы. И внутри есть база на 1Мб сырого json'a, которая затаскивается в общий бандл приложения и ужимается до 150кб. И из-за этого хака всё успешно хостится как статика на Digital Ocean'e за 0.00$ в месяц. Дизайн тоже корявенько делал я. И запросы к Гитхабу — клиентские, лимиты запросов — только клиентские. Легчайшая поддержка.
Из того, что осталось доделать: стили на небольших экранах немного едут, но не критично.
Во славу NJARANA, австралийского бога сна хороших собак.
https://newprojectname.dev
Forwarded from ya mpa 🌲
Proposal #666
Вместо обычных лайфтаймов переменных в расте использовать:
Вместо обычных лайфтаймов переменных в расте использовать:
fn something<á, е́, ó>(ap: &á T, bp: &é T) -> &ó T#prog #cpp #article
Валидатор (и папир о нём) компиляций, проводимых LLVM, по отношению к многопоточным программам. Поспособствовал выявлению нескольких багов в LLVM.
"We construct a validator that checks whether the transformations performed by LLVM are correct according to the C11 memory model or our inferred LLVM memory model. The validator takes as inputs the programs before and after a set of transformations. It compares them by matching their memory access patterns and reports on whether it could find a matching demonstrating that transformation is correct."
Анализатор, к сожалению, не вполне справляется с циклами и использует для них эвристику, которая может поймать только неправильную компиляцию между первыми двумя итерациями цикла. Это вполне объяснимо, поскольку частью анализа является сопоставление потока исполнения программы до и после трансформаций, а эта задача с введением циклов резко усложняется. Для программ же без циклов проводимый анализ точен и корректен (sound).
Надо отметить, что модель памяти, подразумеваемая LLVM, менее строгая, чем модель памяти C11, поскольку допускает добавление спекулятивных доступов к значениям. В связи с этим валидатор может работать, проверяю корректность трансформаций на основе обоих моделей.
Валидатор (и папир о нём) компиляций, проводимых LLVM, по отношению к многопоточным программам. Поспособствовал выявлению нескольких багов в LLVM.
"We construct a validator that checks whether the transformations performed by LLVM are correct according to the C11 memory model or our inferred LLVM memory model. The validator takes as inputs the programs before and after a set of transformations. It compares them by matching their memory access patterns and reports on whether it could find a matching demonstrating that transformation is correct."
Анализатор, к сожалению, не вполне справляется с циклами и использует для них эвристику, которая может поймать только неправильную компиляцию между первыми двумя итерациями цикла. Это вполне объяснимо, поскольку частью анализа является сопоставление потока исполнения программы до и после трансформаций, а эта задача с введением циклов резко усложняется. Для программ же без циклов проводимый анализ точен и корректен (sound).
Надо отметить, что модель памяти, подразумеваемая LLVM, менее строгая, чем модель памяти C11, поскольку допускает добавление спекулятивных доступов к значениям. В связи с этим валидатор может работать, проверяю корректность трансформаций на основе обоих моделей.
plv.mpi-sws.org
Validating Optimizations of Concurrent C/C++ Programs
#prog #rust #article
Статья (pdf) с эмпирическим изучением связанных с memory safety багов в программах на Rust.
Из примечательного:
Среди багов много категории buffer overflow, причём паттерны схожи с теми, которые допускают при написании программ на C и C++.
Из-за дропов в Rust очень просто сделать ошибку double free, поскольку вызов деструкторов нужно отменять явно. Как оказалось, ManuallyDrop лучше подходит для этого, чем mem::forget.
Статья (pdf) с эмпирическим изучением связанных с memory safety багов в программах на Rust.
Из примечательного:
Среди багов много категории buffer overflow, причём паттерны схожи с теми, которые допускают при написании программ на C и C++.
Из-за дропов в Rust очень просто сделать ошибку double free, поскольку вызов деструкторов нужно отменять явно. Как оказалось, ManuallyDrop лучше подходит для этого, чем mem::forget.
doc.rust-lang.org
ManuallyDrop in std::mem - Rust
A wrapper to inhibit compiler from automatically calling `T`’s destructor. This wrapper is 0-cost.