S>>let layout = Layout::new::<*mut MyStruct>(); // выделяем размер указателя
S>>let ptr = alloc_zeroed(layout) as *mut MyStruct;
S>>
Pzz>А что опасного в том, чтобы выделить память под сишную структуру?
Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
Но в Rust такое возможно только в unsafe, а это очень важно данная концепция.
S>>В Rust-команде можно договориться что unsafe пишет только тимлид, а всем остальным это слово запрещено использовать. Pzz>И как же все остальные достигнут нормальной квалификации, если им запрещено программировать?
Им разрешено в песочнице — без unsafe. Там особого вреда причинить не смогут, так что норм. И такого кода как раз 80% а то и более.
Здравствуйте, Pzz, Вы писали:
S>>Беда в том что Rust как раз на порядок сложнее в освоении, нежели C++ Pzz>Почему он сложнее?
Выше ответили. Вообще на нем писать не комфортно как-то, по этому за десятилетия не особо стал популярным. Возможно даже победят расширения для безопасности памяти C++ или Carbon-lang.
Здравствуйте, Nuzhny, Вы писали:
Pzz>>Всего на 20%? А топик начинался так, словно в расте вообще ошибок не делают.
N>Это же разные штуки: ревизии в коде и число уязвимостей.
Здравствуйте, Shmj, Вы писали:
Pzz>>А что опасного в том, чтобы выделить память под сишную структуру?
S>Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
Я уже понял, да. Сам на это несколько раз попадался.
В принципе, в C++ есть new, а в C это лечится простым макросом-обёрткой:
#define NEW(T) ((T*) calloc(1, sizeof(T)))
В целом, фишечка неприятная, но не прям ужас-ужас-ужас.
S>>>В Rust-команде можно договориться что unsafe пишет только тимлид, а всем остальным это слово запрещено использовать. Pzz>>И как же все остальные достигнут нормальной квалификации, если им запрещено программировать?
S>Им разрешено в песочнице — без unsafe. Там особого вреда причинить не смогут, так что норм. И такого кода как раз 80% а то и более.
У меня джуны участвовали в написании ядерных драйверов. Задачи им, ставились, конечно, попроще, чем не джунам, но они писали настоящий код, без наручников на своих руках. Я потом просматривал, чего они понаписали.
А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
Здравствуйте, SkyDance, Вы писали:
Pzz>>Почему он сложнее?
SD>Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
Ну т.е., заставляет быть очень эксплицитным в отношении своих намерений.
Ну, не знаю, кто как, а я всегда так делаю. С самого начала, как программировать начал. А тут еще и синтаксис есть прям в языке.
Меня в расте смущает скорее не требование явно выражать свои намерения (из которых следует необходимость их наперёд для себя сформулировать), а синтаксис евонный, который кажется мне слишком уж вычурным и барочным, без нужды.
SD>Примерно как с тестами. Если их не написать с самого начала, то зачастую можно быстрее отправить какой-то код в прод. Зато потом...
Сейчас скажу крамольное. Если быть предельно откровенным, у меня сложное отношение к тестам.
Да, я понимаю, код с тестами воспринимается с большим доверием, чем код без тестов, и всячески изгибать его потом комфортнее, потому что тесты ловят за руку, когда случайно сломал (и поощряют экспериментировать, толком не разобравшись).
Но тесты минимум в два раза увеличивают цену написания, при том нет ощущения, что это компенсируется соответствующим уменьшением цены развития и поддержки.
Заметим, код условного ядра UNIX, как Linux так и BSD, особо-то тестами не покрыт. Что не мешает быть ему вполне качественным и надёжным.
Здравствуйте, Pzz, Вы писали:
Pzz>Заметим, код условного ядра UNIX, как Linux так и BSD, особо-то тестами не покрыт. Что не мешает быть ему вполне качественным и надёжным.
Есть такое. Тут чисто вопрос экономики — написание авто-тестов стоит дорого и все-равно можно пропустить важные проверки. Чаще всего лучше проверить вручную тот код, который был изменен.
Здравствуйте, Pzz, Вы писали:
Pzz>У меня джуны участвовали в написании ядерных драйверов. Задачи им, ставились, конечно, попроще, чем не джунам, но они писали настоящий код, без наручников на своих руках. Я потом просматривал, чего они понаписали.
Pzz>А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
Бизнес об этом не думает. Пусть пишут свои опенсорсные проекты, доказывают что умеют — и уже потом бизнес их возьмет и доверит — а обучать сейчас не будут.
Здравствуйте, Shmj, Вы писали:
Pzz>>А как еще научиться, если "вы сначала плавать научитись, а воду в бассеин потом нальём"?
S>Бизнес об этом не думает. Пусть пишут свои опенсорсные проекты, доказывают что умеют — и уже потом бизнес их возьмет и доверит — а обучать сейчас не будут.
А где этот бизнес собирается брать готовых сеньёров, если он не хочет обучать джунов?
Здравствуйте, SkyDance, Вы писали:
Pzz>>Почему он сложнее?
SD>Потому что заставляет тебя заранее исправить всю кривизну (ту самую, что ведет к уязвимостям). Заставляет разобраться до того, как все будет работать в проде. Еще на этапе компиляции. Понятное дело, что первоначальные затраты заметно выше. И так же понятно, что потом это поддерживать проще.
Про поддержку вообще не факт. Допиливать мелочи — может быть. А вот рефекторинг может оказаться фатальным.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, Shmj, Вы писали:
S>Так тут вы выделяете память под один указатель, то есть 8 байт. А в голове у вас как будто под структуру. И потом будете писать в размер структуры, которая более 8 байт, а там уже совсем другие данные
S>Но в Rust такое возможно только в unsafe, а это очень важно данная концепция.
Здравствуйте, Pzz, Вы писали:
Pzz>А не может быть так, что это очень молодой код, в котором просто еще не успели найти уязвимости?
В тексте прямо говорится, что для молодого кода они всё и считают:
Накопленная статистика подтверждает ранее высказанное предположение, что основным источником проблем с безопасностью является новый код, а для старого кода наблюдается экспоненциальная зависимость безопасности от времени — со временем в старом коде ошибки выявляются всё реже и реже. В конечном счёте в Google решили не пытаться переписать старый код на языках безопасно работающих с памятью, а сосредоточиться на использовании подобных языков для нового кода.
Pzz>Ну т.е., заставляет быть очень эксплицитным в отношении своих намерений.
Именно! Заставляет разобраться (!!!) в том, что ты делаешь. У нас, старичья, желание разобраться в том, как что работает, было ключевым — мы поэтому и стали заниматься компьютерной техникой. Сначала, конечно, разобрав все в доме будильники, чайники и что еще под руку могло попасться.
Но современные железяки просто так не разберешь. А порой так и вовсе не разберешь. Они слишком сложные, и слишком не-обслуживаемые. Поэтому уже нет стремления разобраться, как и что работает, и что ты хочешь сделать. Напротив, все ушло в некоторые слабо формализованные вероятности — "хочу вот как-то так".
Pzz>Меня в расте смущает скорее не требование явно выражать свои намерения (из которых следует необходимость их наперёд для себя сформулировать), а синтаксис евонный, который кажется мне слишком уж вычурным и барочным, без нужды.
Не, ну это придирки, или вопрос вкусовщины. Выглядит чутка непривычно, но, в целом, вполне разумно. А главное — не так многословно, как это в managed языках типа жабы и аналогов.
Pzz>Да, я понимаю, код с тестами воспринимается с большим доверием, чем код без тестов, и всячески изгибать его потом комфортнее, потому что тесты ловят за руку, когда случайно сломал (и поощряют экспериментировать, толком не разобравшись).
Так это по определению и есть "поддержка старого кода". Более того, если приучить себя начинать с тестов, то и новый код пишется намного более прямой и понятный. Это всего лишь следующий шаг по лестнице грамотности программиста. Он редко случается сам собой. Как правило, нужно активно об этом думать — не о том, чтобы "пофиксить баг", а о том, чтобы написать тест, который баг воспроизводит. Через какое-то время начинаешь прозревать, насколько это меняет даже само восприятие программирования.
Pzz>Но тесты минимум в два раза увеличивают цену написания, при том нет ощущения, что это компенсируется соответствующим уменьшением цены развития и поддержки.
Поэтому и стараются перенести тривиальные тесты прямо в сам язык. И Rust как раз в этом хорош — система типов и подход к менеджменту памяти позволяют обойтись без (порой нетривиальных) тестов. Это все часть подхода "shift left" — когда обнаружение проблемы происходит на как более раннем этапе. Сначала это было в проде. Потом уже в стейдже. Потом на этапе е2е тестов, потом — интеграционных, потом — юнит. Сдвигай на еще один шаг — и вот тебе уже компилятор скажет "атата". Дальнейший сдвиг (еще до этапа написания кода, уже во время обсуждения "а надо ли вообще такой код писать") куда более сложный и пока не очень автоматизирован.
TB>Про поддержку вообще не факт. Допиливать мелочи — может быть. А вот рефекторинг может оказаться фатальным.
Конечно! Тут уже верно указали — количество дефектов напрямую зависит от новизны кода. Если был сделан большой рефакторинг, то есть много нового кода, при прочих равных (*) поначалу будет намного больше ошибок. На С/С++ эти ошибки будешь ловить уже после ухода в прод, а на Rust — еще на этапе компиляции (что, конечно же, поначалу замедлит рефакторинг).
(*) под прочими равными понимается неизменность общей архитектуры и тулинга. Если этот рефакторинг, например, перенес весь код из unsafe в safe, или вовсе на какой-то более высокоуровневый язык, подобные сравнения могут быть неприменимы.
Здравствуйте, SkyDance, Вы писали:
SD>Но сам этот параметр (багов на строку кода) неверный, т.к. некоторые языки уж очень многословные. Есть известное исследование от Ericsson, когда они свою С/С++ систему переписали на Erlang, и там стало в 4 раза меньше строк кода (при той же плотности багов на строку, то есть общее количество багов снизилось в 4 раза). То самое подтверждение формулы Эйнштейна, E=m*C^2. SD>Errors = More * Code ^ 2.
А как меняется количество строк при переписывании с С++ на С++? ИМХО, если взять какой-нибудь большой проект на С++98 и переписать на С++20, то он тоже легко в 4 раза меньше может стать по количеству строк.
Здравствуйте, Skorodum, Вы писали:
S>А как меняется количество строк при переписывании с С++ на С++? ИМХО, если взять какой-нибудь большой проект на С++98 и переписать на С++20, то он тоже легко в 4 раза меньше может стать по количеству строк.
Есть подозрение, что тамошний код при переписывании с C++98 на C++98 можно было бы раза в полтора-два уменьшить.
Вообще C++ на так уж и сложен и небезопасен. Просто значительно выросло количество естетов, стремящихся с помощью его всевозможных примочек усложнить код и порой как следствие сделать его и небеопасным и непонятным и неподдерживаемым. Так языки, где возможности для извращений ограничены или вовсе отсутствуют, становятся безопасными и эффективными.
