Обновить

Комментарии 6

Классика – неэффективное решение на Rust сравнивают с эффективным на другом языке.

> Компромисс Раста в том, что язык агрессивно диктует вам архитектуру

Бред.

Пугать в наше время переполнением буфера можно только тех, кто не может почитать man mprotect и догадаться выровнять и обернуть буфер двумя защитными страницами памяти.

А еще авторов zig (и ржавчины тоже) можно отправить почитать про memory pools and resource management, в такие проекты как APR, postgresql (там они называются Context, Resource Owners) и т.д.

Хотя зачем... как тогда отделять С от .. как там было сказано - "адекватных" :) его замен?

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

И каким образом это делать в общем случае, контроль этот? Встроенные в язык и его runtime проверки это очень хорошо, но память в процессе общая, при желании кто угодно может писать куда угодно даже в случае Java, если только нет защиты памяти на запись на уровне OS (которую впрочем так-же легко выключить, как и включить).

Cуперзащищеннный на уровне языка и runtime буфер может быть поврежден просто вызовом сторонней функции, в новой версии которой, недавно полученной по dnf update вдруг внезапно появился вызов sprintf()

Ну если вы не знаете какие функции у вас в программе куда пишут, то я даже не знаю...

Вот и выросло поколение программистов, для которых написать корректный код, который не вываливается за границы массива - что-то из области научной фантастики…

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации