Это с хабра про Redox 0.6 я не сцелью потролить,

интересно просто, я далек от раста, но немнооожечко писал и там куча всяких заморочек с объектами и владением, по всяким заявлениям должно исключить утечки памяти, тогда откуда они взялись ?

Во-первых, Redox, разумеется, написан на unsafe rust. Во-вторых, даже если бы в нём не было unsafe-кода, утечки памяти — безопасны.

утечки памяти — безопасны отэто прям немного аж замкнуло, даже не буду спрашивать почему, потому что работать надо ... )

std::mem::forget, бокс лики, ссылки это всё сейф же. там ведь это уже вроде объясняли в комментах ниже

Нет ничего принципиально небезопасного в утечках памяти. Они не вызывают UB, просто твоя программа использует больше памяти, чем могла бы.

А какой язык, Вы думаете, гарантирует обязательную рекламацию всей недоступной памяти? 😊

понял, я тригернулся предложением и сразу начал строчить вам )

Brainfuck.

я вообще не про какие гарантии не спрашивал, но и "утечки" кажется другое позразумевают

mark&sweep gc после какой-то там итерации

Если вы будете выделять под свой массив объектов по 2 мб, а реально ваших объектов там на 1,1мб, и так каждый раз, считается ли это утечкой памяти? по сути - да)) Безопасно ли то, что под ваши объекты выделяется доп память и не очищается? Ну как бы да, программа же не ломается, просто чуть больше памяти заняла под себя 😉

"не очищается" пока массив нужен или вообще ? )

Инфа 100%? 😂

Да.

Да? После какой же? А если он не запускался вообще? 😉

Да то же самое: память недоступна ни приложению (нет указателей на неё), ни ОС. 🤷‍♀️

Ну да, вам каждый раз нужно создать массив и им пользоваться, но вы постоянно занимаете больше места, чем вам нужно почти в 2 раза, по сути - в какой-то момент памяти вам нужно будет 1.1 гб, а вы выделили 2гб, просто часть не использовали. Да это не класический пример, но это пример, чтобы объяснить что утечки это безопасно, это не сломает вашу программу в прямом смысле слова 😉

ну не сломает и ладно, тогда зачем ото все владение памятью такое сложное в расте ?

Так разве ж утечки это единственная проблема?)))) Их же этих проблем из-за которых возникают поломки программ куча))

Вообще-то сломается, когда её прибьёт OOM-killer.

Можно запретить OOM-киллеру трогать нашу программу

это несущественная деталь, потому что OOMKiller придет когда хочет.

Это форсмажор 😄

Гм. Если для кого-то несущественно, что его программа инициировала запуск OOM-killer-а, потому что запрограммирована жрать память, то, как говорится, хозяин-барин, добавить тут нечего.

для стандарта языка это действительно несущественно

А если бы я задействовал все 100% аллоцированной памяти, то OOM killer бы не убил мою программу при нехватке памяти?

а разве утечка памяти не может привести к DOS уязвимости?

Это не уязвимость в строгом смысле слова и уж точно не имеет никакого отношения к безопасности по памяти

смотря как он настроен)

Ну, тут уж моя программа ничего поделать не может)

Да, знакомая позиция: OOM и переполнения стека не считаются UB. Звучит парадоксально, но дизайнерам ЯП так проще творить, наверное.

если мне не изменяют знания, то размер стека можно увеличить и тогда то, что ломалось бы при меньшем размере, на большем размере может отработать без проблем))

Он же не целиком на нем написан