В чем смысл Rust?

Firkax — тролль, а второй случай возможен и с Rust:

— ИСПРАВЬ БИТЬЕ В UNSAFE СРОЧНО!!! У МЕНЯ СЕГФОЛТ С ТАКОГО!!! — ПОКАЖИ СТРОЧКУ, ГДЕ Я ПАМЯТЬ БЬЮ!!!, —

иными словами, в семье не без урода.

Cargo.

В пере-писывании на пермессивные лицензии для осуществления стратегии Embrace & extend & extinguish.

Чтобы можно было писать программы в парадигме явного владения.

Но растеры говорят, что их язык нужен для безопасной памяти.

Как будто что-то плохое

Я уже и так знал, что растеры — мазохисты.

Сишные программисты не проблема Си. Сишные программы, написанные сишными программистами, не проблема Си. Проблемы в сишных программах, написанных сишными программистами, не проблема Си. Си вообще ни при чём, когда обсуждаются какие-либо проблемы программирования.

Но когда в Rust-программе находят логическую дыру/дыру с памятью в unsafe, то растеры сразу говорят, что это не проблема Rust’а.

Просто на OpenNET не пишут новости об отсутствии уязвимостей, связанных с памятью, в 95% программ на Си.

Но в любом случае делается проверка логической работоспособности программы. А если писать неопределенный размер данных в фиксированный по размеру буфер, то тут и без запуска всё понятно.

Речь шла о неизбежности совершения человеком ошибок в коде на Си на определённое количество строк кода. Если вы с эти не согласны, то покажите такого гения, который написал значительное количество нетривиального кода на Си без единой ошибки. Его ждёт запись в книгу рекордов Гиннесса.

Все отцы UNIX без исключений совершали значительное количество грубых ошибок в коде на Си, приводящих к порче памяти, аварийному завершению или возможности установки вредоносного ПО через специально сформированные входные данные. Можете сами посмотреть архивные исходники и убедиться.

Высоконагруженных при тестировании программ очень мало.

Если проблема возникает, например, при race condition

Обычно такие проблемы выявляются и без запуска программы, тут такая же история, как и с записью неопределенного кол-ва данных в фиксированный буфер.

Если говорить о всех классах ошибок, включая логические, то да. Но некоторые языки вроде Rust или Java позволяют избежать целый класс ошибок, в результате при правильном использовании в коде на этих языках ошибок будет суммарно меньше, чем в коде на Си.

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

А уже можно без ансейва сделать связные списки на раст?

Если программист пишет неопределенное кол-во данных в фиксированный буфер, то такое пресекается еще до написания даже такого кода.

Тут и без запуска понятно даже обезьяне, что это дыра.

Только Valgrind ее тебе не увидит, вот же какая досада.

Тут такой результат и без запуска кода понятно. Если в программе где-либо есть фиксированные буферы, то работать с ними всегда надо крайне осторожно.

Но увидит человек. Минусы будут?

Неудивительно, что растер еще и нейронкой пользуется. Но в чем смысл, если сам компилятор без Интернета не собрать никак?

Хуже, т. к. предсказать всё невозможно.

Покидал и не раз.

Но увидит человек. Минусы будут?

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

Этот мир обречен

Речь шла о неизбежности совершения человеком ошибок в коде на Си на определённое количество строк кода.

Через 100 миллионов строк кода, хотел сказать?

Все отцы UNIX без исключений

До появления червя Морриса о таких проблемах не думали.

Тут такой результат и без запуска кода понятно.

Кому понятно? Никому не понятно. Если бы всем было понятно, никаких растов не было бы в помине, потому что проблемы выхода за границы буфера не было бы в понине, ведь понятно жэ. Я тебе простой случай для наглядности привёл, хочешь сложные случаи штоле?

Если в программе где-либо есть фиксированные буферы, то работать с ними всегда надо крайне осторожно.

Что за бред. Ну, давай, размер буфера мы будем тоже задавать. Это только осложнит анализ. Фиксированные буферы - _всегда меньше ошибок.

Если программист — дурак и пишет неопределенное кол-во данных в фиксированный буфер, то ожидать от него чего-то большого и значимого не стоит.

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

Эти проблемы в основном встречаются в ядре и в программах от дедов и упрямых ослов, которые не хотят valgrind использовать. Ну, если брать не только людей, то еще у трапов из-за их интеллекта. В приведенном тобой примере в фиксированном буфере ты пытаешься найти элемент с неопределенной позицией в нем.

Что за бред. Ну, давай, размер буфера мы будем тоже задавать. Это только осложнит анализ. Фиксированные буферы - _всегда меньше ошибок.

А в Rust всё еще сложнее. Видимо, у тебя проблемы с самоконтролем, так как Rust заставляет это делать, причем гораздо с большим кол-вом усилий, а Си — нет.

Предсказать всё невозможно, а валгриндом стало быть всё выловить возможно и это быстрее. И как жэ ты такое вычислил? Хорошие таблеточки вы там кушаете.

Если программист пишет неопределенное кол-во данных в фиксированный буфер, то такое пресекается еще до написания даже такого кода.

Это как технически реализовано?

Речь шла о неизбежности совершения человеком ошибок в коде на Си на определённое количество строк кода.

Повторяю, не подменяй тему. Во-первых, речь шла конкретно про битьё памяти а не про любые ошибки. Во-вторых, речь шла про невозможность написать вручную (без дополнительных инструментов-проверяльщиков) прогу на Си без этого битья, а не про то, что что в каком-то недоделанном или невнимательно проверенном коде могут быть проблемы.

Все отцы UNIX без исключений

Я не знаю откуда взялось это мнение про «отцов UNIX» как образцов безопасного кода. Практически весь код из 80-х полон дыр, но не потому что программисты были поголовно тупые, а потому что в те времена об этом практически не думали, комп считали как усовершенствованный калькулятор коллективного пользования. Сейчас подход к программированию кардинально другой, и компетентные программисты в ответственных местах такого уже не допускают. Всякие быдлокодеры разумеется имеют место, и их даже очень много (включая многих контрибьюторов в ядро), но не надо делать некорректных обобщений.

valgrind, товарищ, во многих случаях использовать невозможно, он ограничен. Под моей одиннадцаткой он не работает, например. И под Mac OS Apple Silcon он не работает.

В приведенном тобой примере в фиксированном буфере ты пытаешься найти элемент с неопределенной позицией в нем.

Ой, спасибо за консультацию. Я этого не знал.

А я не растер, я по сишной группе (С/C++/C#) и ещё Python. Сейчас Java взялся тыкать, потому что удобнее чем C# в сложившейся ситуации.

потому что в те времена об этом практически не думали, комп считали как усовершенствованный калькулятор

… и многие вещи считали незыблемыми константами. Отсюда и проблема 2036 года, и «640 Кб хватит всем» и т.д., и т.п. Т.е. если некоторые величины ограничены тупо физикой Вселенной, - их и сегодня никто не проверяет за ненадобностью. Вот только, программисты всех времён за Вселенную нередко считали свой маленький манямирок. У кого кругозор был пошире, - да, таких ошибок не допускали

Проблема 2038-го. Проблема 2036-го года тоже есть, но она другая. В ntp пакете время идёт до 2036-го года. Это их не беспокоит, они уверены, что так можно. Посмотрим.

Сравнивать Си с valgrind и Rust, это как говорить, что можно срать в штаны, а потом их стирать, вместо того чтобы пользоваться туалетом.

Высоконагруженных при тестировании программ очень мало.

Если программа не должна иметь топовую производительность, то нет большого смысла брать Си. Ведь тогда можно взять другой язык, где ошибки с памятью отсутствуют как класс, за счёт меньшей производительности.

А если нет возможности проверить, как программа работает под высокой нагрузкой, значит по сути код не протестирован.

Обычно такие проблемы выявляются и без запуска программы

Выявление race condition зачастую требует ментальной модели всей программы, ведь по отдельным участкам кода не понятно, из каких тредов какой доступ к каким данным может осуществляться. Это наверное одна из самых сложных ошибок для обнаружения.

Если честно, складывается впечатление что ты разработкой софта вообще не занимался никогда. Догматизм типа «только bash или C» очень легко разбивается о реальность.

Во-первых, речь шла конкретно про битьё памяти а не про любые ошибки.

Ну покажите хоть один крупный проект на Си, где нет ни одной ошибки, приводящий к порче памяти. В ядре Линукс регулярно такое находят. Да даже в мелочи вроде libpng находили.

Если программа не должна иметь топовую производительность, то нет большого смысла брать Си. Ведь тогда можно взять другой язык, где ошибки с памятью отсутствуют как класс, за счёт меньшей производительности.

Другим преимуществом сишечки, является компактный портированный на каждый чайник рантайм. Забубенивать ваш раст в контроллер, я не буду. Он там и не заработает никогда.

Другим преимуществом сишечки, является компактный портированный на каждый чайник рантайм. Забубенивать ваш раст в контроллер, я не буду.

В целом эмбедд это последняя пристанище сишечки, больше нигде этот язык не используется толком.

Другим преимуществом сишечки, является компактный портированный на каждый чайник рантайм.

Как раз у Си с портируемостью беда. Полно кода завязано на расширения конкретного компилятора вроде GCC или MSVC. Много где используются ОС-специфичные API. По всюду код обвешан всякими #ifdef __OS_NAME__. Код на Rust как раз будет портируемее. Не говлря уже о Java или Python.

А зря это тоже возможно, причем еще и в нескольких вариантах, без os, c freertos, с embassy, еще там какаято tos есть, с std, без std и тд, под большинство популярных контроллеров.

А, вспомнил, ты ж Ленин, у тебя Linux может быть только на серверах. В таком случае могу предложить лишь в виртуалке с Linux писать на Си.

Ой, спасибо за консультацию. Я этого не знал.

С фиксированными буферами нельзя делать ничего неопределенного.

2036

640 Кб

Для многих задач их DOS’а действительно хватает.

Почему сразу в штаны? В унитаз.

Господи, ну пусть они будут не фиксированными. Тебе переписать пример штоле? Для наглядности и простоты сделал, чтобы было понятно, что работа валгринда от входных данных зависит напрямую. Есть целый класс ошибок, называемых «надежда на хорошие данные». Когда программист надеется, что данные для его программы будут тёплыми и мягкими. Точнее сказать, мало думает и анализирует. А как только входной файл чуть не такой - бац, бум, ой.

Если программа не должна иметь топовую производительность, то нет большого смысла брать Си.

Я говорю: при тестировании.

Выявление race condition зачастую требует ментальной модели всей программы

Ты что, вайбкодер, что она отсутствует у тебя? Или ты вместе с макаками пилишь софт?

Догматизм типа «только bash или C» очень легко разбивается о реальность.

Я сказал, что питон не нужен, я не говорил, что имеют право на существование только Си и bash. C++ я не люблю, но смысл у него есть, в отличие от Rust.

Для многих задач их DOS’а действительно хватает.

А ещё для многих задач DOS’а внезапно не хватает.

В ядре Linux valgrind использовать нельзя, а libpng писали индусы.

80% прикладухи написано на C/C++.

Пруф

За термин «С/C++» я бы гнал из профессии с волчьим билетом. C++ - это другой язык!