И это всё не имеет абсолютно никакого смысла, пока C и C++ никак не защищают от случайного написания кода подобного *((size_t*)0) = 0; в обход всех этих ваших SafePtr
Мне никогда не приходилось использовать двусвязные списки в своей практике, так что я не вижу смысла решать задачи, не имеющие практического смысла, нормальный рациональный программист возьмёт Vec и не будет выпендриваться
Ага, «в расте есть RefCell и утечки ужас-ужас», «в unsafe-коде можно ошибиться ужас-ужас», «в расте куча runtime-проверок», «борроу-чекер мешает писать код» и прочая классика растосрачей, каким пунктом там cve-rs в методичке?)
1) Просто не используйте unsafe-крейты, которым вы не доверяете
2) Если вы всё же хотите или вынуждены их использовать, при получении рандомного числа из ниоткуда вы точно знаете, что виновником может быть только один из unsafe-крейтов и никто другой, что существенно сужает круг подозреваемых и ускоряет отладку — чем Rust и прекрасен в сравнении со всякими сишечками
Если перестать фокусироваться на несчастном RefCell, а взять хоть тот же условный Vec, проверки там — где надо, где они должны были бы быть и в аналогичном сишном коде тоже. Считать проблемой то, что необходимые runtime-проверки есть — глупо. Игнорировать то, что компилятор способен выкидывать runtime-проверки и обеспечивать отсутствие оверхеда, тем самым опровергая ваши утверждения, — дважды глупо
Вот собственно с того ветка и начинается, что не надо открывать доступ к redis и rabbitmq из интернета (на вопрос «зачем» никто так и не ответил)
А вот нифига, образ с elasticsearch 8.2 не запускается на современных линуксах например
Нынче изоляция легко делается через systemd
Ну если вы в своём готовом образе сами сознательно добавили дыру, то вы просто очень глупенький, наверное?
Ключевое — DOMContentLoaded, обычно нет смысла ждать завершения загрузки всяких маловажных картинок
Я пытался её использовать, но оказалось, что у неё слишком много ложноположительных срабатываний
И это всё не имеет абсолютно никакого смысла, пока C и C++ никак не защищают от случайного написания кода подобного
*((size_t*)0) = 0;в обход всех этих ваших SafePtrА что принципиально изменилось? Просто убираем
= 666и получаемfree(): invalid pointerВы о чём вообще?
Код по ссылке легко валится написанием какого-нибудь банального
*(SafePtr((int*)666)) = 666;На Rust вы не сможете так сделать, не используя unsafe — тем Rust и прекрасен
На фоне сишечек — уже огромное достижение
Можно настроить одинаковое поведение
На свежеустановленном сервере никаких redis и rabbitmq тем более не существует
То есть вы потеряли микросекунды и получили проблему 2038 (или 2106) года?
Мне никогда не приходилось использовать двусвязные списки в своей практике, так что я не вижу смысла решать задачи, не имеющие практического смысла, нормальный рациональный программист возьмёт Vec и не будет выпендриваться
Ага, «в расте есть RefCell и утечки ужас-ужас», «в unsafe-коде можно ошибиться ужас-ужас», «в расте куча runtime-проверок», «борроу-чекер мешает писать код» и прочая классика растосрачей, каким пунктом там cve-rs в методичке?)
Куча CVE наглядно демонстрирует как там все начеку)
Всяко лучше чем у сишечек
Из коробки не завезли, но есть cargo-geiger какой-нибудь
1) Просто не используйте unsafe-крейты, которым вы не доверяете
2) Если вы всё же хотите или вынуждены их использовать, при получении рандомного числа из ниоткуда вы точно знаете, что виновником может быть только один из unsafe-крейтов и никто другой, что существенно сужает круг подозреваемых и ускоряет отладку — чем Rust и прекрасен в сравнении со всякими сишечками
Если перестать фокусироваться на несчастном RefCell, а взять хоть тот же условный Vec, проверки там — где надо, где они должны были бы быть и в аналогичном сишном коде тоже. Считать проблемой то, что необходимые runtime-проверки есть — глупо. Игнорировать то, что компилятор способен выкидывать runtime-проверки и обеспечивать отсутствие оверхеда, тем самым опровергая ваши утверждения, — дважды глупо