Компания Checkpoint представила механизм защиты Safe-Linking, позволяющий усложнить создание эксплоитов, манипулирующих определением или изменением указателей на буферы, выделенные при выполнении вызова malloc. Safe-Linking полностью не блокирует возможность эксплуатации уязвимостей, но при минимальных накладных расходах существенно усложняет создание эксплоитов, так как помимо эксплуатируемого переполнения буфера необходимо найти ещё одну уязвимость, вызывающую утечку сведений о размещении кучи (heap) в памяти...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53013
Чего только люди не придумают, лишь бы не писать на memory-safe языках...
потому-что есть разница между +3~4 строками ассемблема и +over9000
Кто заплатит за оверхед пистона и пр. высокоуровневой мути в системный библиотеках?
Пользователи, конечно! Что за странные вопросы...
В самом деле. Как только не изголяются, чтобы не потерять половину производительности на ровном месте.
Правильно нужно на РАСТЕ всё писать
И тогда троянцев вгрузят прямо из хранилища карго-культа, оптом. Всем и сразу. Вы же не хотите сказать что мозилла может сколь-нибудь безопасно это содержать?
Да, а параметры в функцию передавать через https+jsob/bsonБинарные файлы вообще хранить в строках base64 и пото всё это постоянно парсить, писать парсеры парсеров парсеров парсеров, чтобы обпарсилось всё в хлам.
И везде должны быть гамбургеры меню.
Как ты умудрился всё это у себя в голове с ржавчиной связать?
Код на ржавчине наверное позырил. Там такие конструкции попадаются что им даже самые тертые плюсовики-извращенцы позавидуют.
> Как ты умудрился всё это у себя в голове с ржавчиной связать?Очень просто. Горепрограммисты обычно такую кашу и делают. И обычно именно горе програмисты и кричат больше всего что rust спасёт мир и это единственно верный язык. Слепо веря что компилятор вылечит их от тупости.
> лишь бы не писать на memory-safe языках...Ну тогда и ножик с кухни выкинь, им порезаться можно.
Мозг надо выкинуть, он иногда сбоит и подталкивает к самоубийству.
Какие только memory-safe языки не придумают, лишь бы не учиться нормально программировать...
Так он не memory-safe внезапно. Это идиотская видимость.Внезапно C++ тоже memory-safe. Пользуйся исключительно stl, не пользуй динамическую память напрямую (аля safe - unsafe в rust), которого хватает для 90% задач и не будет проблем. Внутри работа с памятью выверена и перепроверена десятелетиями. Тот-же unsafe внутри rust от которого они так кипятком писают.
Просто когда у человека в колове полный unsafe то ему ни один язык уже не поможет. Там уже топор нужен.
Если на то пошло - в сях так например никто и не заставляет pointer'ы использовать, равно как и динамическое выделение памяти. И поэтому при наличии желания можно и на сях безопасно и предсказуемо, а при отсутствии и на пыхапэ сплошная дыра получается, хоть там и нет указателей.
> Если на то пошло - в сях так например никто и не
> заставляет pointer'ы использовать, равно как и динамическое выделение памяти.Если память распределена статически, её объём фиксирован и, в общем случае, недостаточен.
> Если на то пошло - в сях так например никто и не
> заставляет pointer'ы использовать, равно как и динамическое выделение памяти. И поэтому
> при наличии желания можно и на сях безопасно и предсказуемо, а
> при отсутствии и на пыхапэ сплошная дыра получается, хоть там и
> нет указателей.Это кстати именно так. К слову в контроллерах вообще не используется динамическая память. И ничего, пишут на c\c++ и проблем не знают.
Я все время говорю что rust гораздо более опасный язык программирования чем Си. Одни только unsafe блоки чего стоят.
Никто не будет писать системное по на опастном rust если есть более безопасный Си в котором нет unsafe блоков
> Я все время говорю что rust гораздо более опасный язык программирования чем
> Си. Одни только unsafe блоки чего стоят.
> Никто не будет писать системное по на опастном rust если есть более
> безопасный Си в котором нет unsafe блоковВот и я о примерно тоже.
А что, в memory-safe языках под капотом не malloc/free?
В том же Расте вроде нет.. раньше. Но тогда хэллоувроды весили под 300Кб ( на асм - 2Кб и то, из-за выравнивания и проч, т.к в секции кода оставалась куча неиспользованного пространства ).
А потом.. в потом - господа решили использовать для работы с памятью системное апи.
Хотя мб я и ошибаюсь..В случае с остальными.. а такие вообще реально существуют ?)
Всм, чтобы и у прог, написанных на них, никаких проблем не было, но чтобы и кто-то со стороны их "бомбануть" принципиально не мог
Сам то понял что сказал? rust пускается на операционной системе а не в сферическом вакууме.
Сам то понял что сказал ?
Само-собой, что запускается на системе и, в конечном счёте, память запрашивается у неё, но malloc в данном случае - просто сишное поделие и сишная прослойка к ОС и «абстракция»( к примеру, у той же винды, насколько помню, память выделяется посредством winapi VirtualAlloc ).
> Сам то понял что сказал ?
> Само-собой, что запускается на системе и, в конечном счёте, память запрашивается у
> неё, но malloc в данном случае - просто сишное поделие и сишная прослойка к ОС и «абстракция»( к примеру, у той же винды, насколько помню, память выделяется посредством winapi VirtualAlloc ).И заодно рантаймлиба немалого размера - к которой и линкуются все "маленькие" сишные хелловорды. Которые почему-то перестают быть маленькими (или быстрыми - это специально для любителей всяких спец-libc), стоит только сделать
echo 'int main(void) {return puts("hello world!");}' | gcc -xc - -static -Os -s
> на асм - 2Кб и то, из-за выравнивания и проч, т.к в секции кода оставалась куча неиспользованного пространстваТолько это размер Неуловимого Джо - как только нужно cделать что-то помимо вывода простого хелловрода (например, вывести дополнительно результат вычисления FPU), начинается или велосипедизм (причем, примерно со стадии поиска руды и постройки плавильной печи) или применение сишных/иных рантаймов или прибивание полуметровыми гвоздями к конкретной ОС.
> И заодно рантаймлиба немалого размера - к которой и линкуются все "маленькие"
> сишные хелловорды. Которые почему-то перестают быть маленькими (или быстрыми -
> это специально для любителей всяких спец-libc), стоит только сделать
>
> echo 'int main(void) {return puts("hello world!");}' | gcc -xc - -static -Os
> -s
>Сишные приложения и сами по себе не шибко маленькие, так за ними еще и тонны рантайма тянутся - в свое время сильно удивлялся такой сишной "легковесности".
>> на асм - 2Кб и то, из-за выравнивания и проч, т.к в секции кода оставалась куча неиспользованного пространства
> Только это размер Неуловимого Джо - как только нужно cделать что-то
> помимо вывода простого хелловрода (например, вывести дополнительно результат вычисления
> FPU), начинается или велосипедизм (причем, примерно со стадии поиска руды и
> постройки плавильной печи) или применение сишных/иных рантаймов или прибивание полуметровыми
> гвоздями к конкретной ОС.Кому Джо, а кому - и нет.
Порой, довольно интересно, насколько мелкими могут быть конкретные реализации функционала( да и штуковины типа простеньких заражающих вирусов самое то на асме писать ).Вообще, из наиболее интересных на моей памяти "мелких" проектов - была либа т.н HDE( hacker disassembler engine )
- тип постарался написать максимально легковесную библиотеку для анализа х86-бинарей и их инструкций( дизассемблерный движок ), чтобы, по случаю чего, свой код в них куда надо вклинивать, а не в середину конкретной инструкции. Но это было лет 10 назад.
Хотя он вроде и не шибко на асм был написан - тами высокоуровневые языки применялись если память не изменяет.
Но соль в том, что итоговая библиотека весила порядка 900 БАЙТ.
Каких только глупостей люде не придумают лишь бы мозг не включать.
Очень неосмотрительно ассоциациировать попытку привнести больше безопасности в мир с чем-то отрицательным.
Да, полной безопасности не бывает, опасность может затаиться и в языке с VM/GC, и на уровне ошибок железа.
Но если можно что-то автоматизировать, особенно когда это касается безопасности, это НУЖНО делать.И C, и C++ навсегда останутся оружием для стрельбы по ногам, в большей или меньшей степени, при всей моей любви к C++.
И никакой мозг не поможет не совершить ни одной ошибки в коде, если проект больше хелловорлда. Никакой.
> Очень неосмотрительно ассоциировать потакание неряшливости и лености ума с попыткой привнести больше безопасности в мирМожешь не благодарить.
Чушь.
Написание на C не приводит к ряшливости ума, а лишь порождает баги на пустом месте из-за абсолютного unsafe. Которые потом годами могут висеть и внезапно вылезать в самый неподходящий момент как мировая уязвимость.
Любая автоматизация - это благо и повышение эффективности.Естественно, подход раста не панацея, но безопаснее, при этом он удобнее для рутинных действий, вроде банального подключения библиотек.
И даёт возможность сосредоточиться на бизнес-логике, а не отладке сегфолтов.
А Вы писали на C и в ваших программах вылезали баги? Или анализировали баги в чужих программах и определили, то они появились благодаря "абсолютному unsafe"?
C++ в основном, в контексте разница не велика, stl или qt core вообще не панацея, а скорее затычка в днище
Баги только логические, а из-за языка сегфолты. Конечно, это дебажится и правится, но веселее править эти падения в чужом коде. Или многопоточном, когда дебаггер иногда сам не выкуривает, где пошло что-то не так
Так что да, из-за unsafe
О чем говорить, если взятие ссылки на элемент в векторе и пуш - это уже жесткое ub
И такие ub на каждом шагу, иногда и не заметишь, и будет годами висеть
Ну не знаю...
Я писал на простом C, у меня всё работало корректно.
Возможно, это специфика плюсов.
Мозилла корп, огестапливающая свою паству там и тут почему-то не ощущается "безопасно".
> Очень неосмотрительно ассоциациировать попытку привнести больше безопасности в мир с чем-то
> отрицательным.
> Да, полной безопасности не бывает, опасность может затаиться и в языке с
> VM/GC, и на уровне ошибок железа.
> Но если можно что-то автоматизировать, особенно когда это касается безопасности, это НУЖНО
> делать.
> И C, и C++ навсегда останутся оружием для стрельбы по ногам, в
> большей или меньшей степени, при всей моей любви к C++.Что-то у меня ничего не падает, не течет и в ногу ни разу не попал. Нет, я не говорю что не делал ошибок, делал, кучу. Огромную кучу.
И что-то тонны прекрасного софта написаны. И с дырами и без.
> И никакой мозг не поможет не совершить ни одной ошибки в коде,
> если проект больше хелловорлда. Никакой.Как и компилятор не поможет.
Умный ходить по минному полю не будет.
> Умный ходить по минному полю не будет.Да госпади, где вы это минное поле то нашли? Хоть бы почитали какие книжки. Пользуйся рамками stl и не будет тебе никакого минного поля. Если у тебя такая паническая атака от одного только упомиания динамической памяти и указателе.
Каких только глупостей люде не придумают лишь бы мозг не включать.
А как же jemalloc? Или он уже не модный? 4 года назад он был эффективней и в отличие от gperftools не вызывал зависаний при половине свободной памяти.
Из того же раста его вроде выкинули-таки..
В расте скорее дали свободу выбора аллокатора и выкинули очередной багаж времён экспериментов в версиях 0.x, когда там был жирный рантайм и зелёные треды. Никто не мешает продолжать линковать приложения с jemalloc, если хочется.
Сколько утомительной работы вокруг сишных дыр...
Давай, фрактал, пришло твоё время, расскажи как правильно, мы внемлим.
Можно забить на программирование и пойти выращивать рассаду. Тогда дыры будут только в земле.
На самом деле, не такая уж и плохая идея. Тем более, как раз самый сезон :)
Хочешь быть передовым - сей квадратно-гнездовым!
Наша главная задача - молотьба и хлебоздача!
Тыб уже написал чтонибудь дельное на своё истинно верном языке который спасает от всех проблем. Что-то такое чем пользоваться можно было бы.
>дельное
>ФракталВыбери что-нибудь одно.
Одни не принимает патч из-за дополнительных 5-7 ассемблерных инструкций, зато другие смело хватаются за электрон при написании хеллоувордов. Эх.
У вторых электрон просаживается в 10 раз когда первые вставляют дополнительные 5-7 ассемблерных инструкций.
И все вместе хватаются за голову когда дополнительные 5-7 ассемблерных инструкций вставляют в микрокод разработчики процов и прошивок. )
А по теме - да, это нужно внедрять, как опцию. Приятным бонусом будет ловля не всегда очевидных сразу блох с указателями.
На rust пиши, проблем не знай.
Дядь, в борьбе с переполнениями есть ровно два варианта - ренжи, которые есть далеко не только в расте, и bound checks, которые тоже можно сделать где угодно, только тупят они тоже где угодно.В общем, как и всё в расте - либо то же самое тривиально делается (и давно стало стандартной практикой) в плюсах - либо тоже тривиально делается, но опционально потому что имеет жирные минусы.
В rust оно всё есть из коробки и для всех, ваш юный джун не обосрется.
Поэтому он наломает дров в десятке других мест. Проверено WormPress'ом и прочими джумлами :)
> На rust пиши, проблем не знай.Красиво было на бумаге, да забыли про овраги. Очередной спаситель человечества. И как обычно карманный проектик одной стремной корпорахи. Примерно как D.
Эй, D вообще не из той серии - там тот же подход, что и в плюсах - все инструменты доступны, выбирай нужное подмножество, никакого концлагеря. Профит исключительно от отказа от исторически накопившихся в плюсах костылей вроде компиляции сишного кода или адски запутанной системы шаблонов.
> выбирай нужное подмножество, никакого концлагеря.Если не считать того что дохрена лет был 1 компилер, делаемый 1 полупроприетарной чтототам-mars-corporation, или как там его. И общего тут то что mozilla corp с примерно теми же причудами в примерно той же позе, только еще чтобы совсем уж концлагерно, репу завели, с нахрапом впаривают и конечно же содержится все это именно той корпой, в последнее время очень переклиненой на том чтобы строить других. Чем, собственно, и заколебали разработчиков своей экосистемы в край.
> На rust пиши, проблем не знай.Именно, всё равно это никому надо не будет, вот и дыр нет.
Чудесно, все прочие тормоза "защит" умножили ещё на один коэффициент. Если всё ампутировать производительность, небось раза в три поднимется.
К счастью, нет, в большинстве случаев это так не работает. Например, эта правка malloc'а не замедляет дополнительно защиту от Meltdown с помощью KPTI, и наоборот. Тут речь идет приблизительно о сложении, а не об умножении. Если попытаться найти пример другой защиты, последствия которой для производительности умножались бы на получаемые от дополнительных инструкций в malloc, в голову приходит только выключение speculative store bypass в CPU, но это сейчас делают только в программах, явно запросивших такую защиту через prctl, и при использовании seccomp.
Конкертно это - пожалуй, да. Но очень интересно было бы сравнить нынешний "дефолтный" код с "чистой" версией - без ASLR, stack protection и прочего, в идеале - с защитой исключительно от ошибок, а не атак.
> с защитой исключительно от ошибок, а не атак.DJB определил уязвимости как ошибки, ведущие к проблемам безопасности. Так что если исключительно все ошибки исключить, проблемы безопасности тоже должны исключиться, как частный случай. Но что надо сделать с людьми чтобы исключить все ошибки в коде - вопрос открытый.
Я имею в виду ситуацию, когда мы вообще никаких атак не ожидаем и не боимся. То есть мы, конечно, не хотим, чтобы по ошибке одно приложение переписало память другого или забрало себе все ресурсы системы (поэтому некоторая изоляция таки нужна), но именно злонамеренных действий не ждём.
> Я имею в виду ситуацию, когда мы вообще никаких атак не ожидаем и не боимся.Для обычного десктопника или сервера это достаточно синтетическая ситуация. Даже просто посмотреть картинку или музычку послушать - уже untrusted input в общем случае.
Единственный юзкейс который я могу вспомнить vs алгоритмы: в демке на speccy чувак юзал unsafe версию декомпрессора, забивающую на проверку всяких глупостей. Ну, в крайнем случае, если демка сдуреет, поезд с рельсов не сойдет, банки не взломают, так что и черт с ним. Вот там на отсутствии проверок у чувака был солидный профит, при ориентации на столь тормозной проц как бы актуально. Однако ценность такого кейса ... вызывает определенные вопросы.
>Но что надо сделать с людьми чтобы исключить все ошибки в коде - вопрос открытый.когда капуста, козы и волки в одной лодке никакие перегородки не спасут. Может все таки архитектура Фон Неймана - УГ?
> Может все таки архитектура Фон Неймана - УГ?Как бы MMU/MPU позволяют разграничивать что и где. А чистый гарвардец офигенная штука. Попробуй блин под него хотя-бы бутлоадер написать. Так что вон в AVR в RAM извне вгрузить прошивалку совсем низя, а в флехе - пока флеха шьется, все встает раком, в том числе и код бутлоадера. И он тупо недееспособен все время пока флеха в ауте, на это время чип становится полной тыквой - и это вообще совсем нельзя обойти.
>Попробуй блин под него хотя-бы бутлоадер написать.Попробуйте сначала разговаривать с машиной на её "языке", а не посредством переводчиков, я бы посмотрел бы сколько Г еще посыпалось из её архитектуры.
>DJB определил уязвимости как ошибки, ведущие к проблемам безопасностиа определение понятию "безопасность" очевидно он не дал :)
Как вы думаете, в природе есть понятие "безопасность" ? По мне - нет, есть понятие "инстинкт самосохранение", и природа создала баланс всех животных, "ахиллесову пяту" имеют все.
> а определение понятию "безопасность" очевидно он не дал :)Оно следует из определения уязвимости по DJB: это в принципе любое поведение программы, которое не было запланировано программистом. Атакующий потенциально может использовать неожиданное для программиста поведение его программы для получения какого-то незапланированного бонуса, в ущерб чьим-то легитимным интересам.
> Как вы думаете, в природе есть понятие "безопасность" ?
Я попробовал доразвить идею.
> "ахиллесову пяту" имеют все.
Люди не умеют писать программы без ошибок. Поэтому как максимум одни классы ошибок мутируют в другие. Ну хорошо, вместо кидисов с переполнением буфера приходит пачка ботов с вордпресовского плагина. Безопаснее это не ощущается.
>Оно следует из определения уязвимости по DJB:когда одно определение следует из другого - это порочный круг, вот вы и доказали, что безопасность это порочный круг ("Щит и меч").
>это в принципе любое поведение программы, которое не было запланировано программистом.
как такое возможно? не запланировано - это как? Может ли быть у детерминированного алгоритма незапланированное поведение?
>Люди не умеют писать программы без ошибок.
Ну так смиритесь с этим, будут и ошибки и заплатки, чем крепче меч - тем крепче и щит, и так по кругу - "порочному".
>Безопаснее это не ощущается.
Потому-что это псевдо-ощущение.
> Если всё ампутировать производительность, небось раза в три поднимется.Да, в всяких там декомпрессорах и парсерах протоколов оборвать к дьяволу проверку валидности входных данных и прочих глупостей. Вот весело будет, когда все это - в интернете!
Правильно, что не приняли этот гимн современного маркетинга.
А то, давайте забьём на качество кода, а вместо этого будем добавлять +100500 тормозящих проверок, а всем будем продавать это как очередную технологию безопасности следующего поколения :)
А мне вот что стало интересно. Сколько процентов производительности процессора занимает дыра в безопасности? Другими словами, насколько упадёт эта самая производительность, если закрыть ну совсем все дыры?
До нуля. Всё, что работает - небезопасно. Ибо может быть сломано. =)
> насколько упадёт эта самая производительность, если закрыть ну совсем все дыры?До нуля. Если компьютер оставить совсем без электричества, его хрен сломаешь, конечно. В остальных случаях - возможны варианты. Людям видите ле свойственно ошибаться.
Пожалуйста уточните, какая конкретно дыра в безопасности ?)
Здравая идея, похожее уже применяется в GCC для защиты функций от переполнения стека. (-fstack-protector)
здравая идея это манагеров интела под суд
и гос. конторы которые у них это закупают (в США конечно, на госконторы богоспасаемых индий пофиг)
помню как в одной конторе работали с гуй-мордой чекпоинтовского фиревола))) применение любых телодвижений с правилами занимало то ли несколько минут то ли еще больше)))
а разве __typeof не GCC специфичная штука? Да не закидают меня помидорами, но разве использование компилятороспецифичных расширений не полный отстой? Это уже получается плохо портируемая разработка не на самом языке, а на его диалекте. Сейчас погуглил - в Clang typeof работает только если врубить режим GNU-совместимости. Для MVSC/Intel C Compiler не нашел, как врубить поддержку вообще. А вот в Tiny C поддержка есть, кек.
Intel C Compiler поддерживает как и большую часть гццшных расширения, MVSC просто не нужен, так не компилятор C, а какое-то недоразумение.
Особо выбора нет. В С++11 есть портируемый declspec, а в чистом С нету. Но реализации malloc обычно тоже плохо портируемы, не лучше, чем тот __typeof. Так что не вижу лучшего решения. А если нужна будет совметимость с другим компилятором, у которого нет __typeof, а есть что-то другое - использовать то другое через #ifdef, как водится.
Решение проблемы косвенными методами - зло. Т.ч. всё правильно сделали.
Вот не дочитал коменты до конца, но в очередной раз увидел и задался вопросом.Отчего сообщество rust такое токсичное?
Чем вот например отличается верующий от сектанта? Верующий верит себе и верит, никому ничего не навязывает. А вот сектант как раз ходит и проповедует что есть только его единственная вера способная спасит твою грешную душу.
К слову, вот есть верующие и атеисты. Сколько в мире религий? Да дохрена. При этом верующий верит в одну из дохрена, а атеист ни в одну. Как-то верующие не далеко ушли.
Другое дело секта, спасители мира блин.
При этом нет ни одного софта на rust которым вот прямо захотелось бы попользоваться. Вот даже на посмотреть. Ни одной тулзы ни одного ничего что нужно в повседневной жизни для работы \ дома.
Сделайте уже что-то дельное на своём rust'е. А то только бла бла бла. Пока нормальные люди пишут нормальный код и что-то ничего ни у кого не падает и не глючит.
Я обычно вижу кучу хейтеров раста, а как раз его приверженцы вполне спокойные и уравновешенные, адекватно вступают в дискуссию. И такое всплывало ни раз, даже на опеннете.
Я понимаю хейт в сторону Раста. Он привлекает, имеет единый компилятор, с которым нет проблем использовать последние фичи языка (например, C++20 по-разному поддерживается в разных компиляторах, а у нас приложение и десктоп, и андроид/айос, и пока нет возможности перейти на него), удобную систему сборки, множество иных удобств.
И, если станет популярнее, это ударит по всем C/C++ спецам, придется переучиваться, переделывать.А какой-то особый софт на Расте не стоит ждать. У него несколько иное применение - системное программирование, бэкенд, встраиваемость в другие программные системы (например, вызов из скриптовых языков)
Для UI он не очень подходит, например. Впрочем, как и C/C++/Java/подробные языки
> имеет единый компиляторЭто всего лишь следствие молодости и "неокреплости" языка. У С, С++ и Явы тоже когда-то был ровно один компилятор.
Не думаю, что когда-нибудь будет такая же жесть, как с плюсами
Да это и не к чему, разве что for fun
Слишком удобно качать всё через rustup
У C/C++ никогда такого не было, как и ведущей компании
> У C/C++ никогда такого не было, как и ведущей компанииТак что визгливые идиотины желающие именно концлагерных порядков от стремной комерсовской корпорашки, по счастью, сольются в те экосистемы. Куда и дорога этим вебмакакам.
Факты говорят сами за себя.
Я люблю C++, но он безнадежно отстаёт.
И во многом из-за разрозненности и хаотичности сообщества.- Куча билд систем. Кто-то может использовать cmake, кто-то qmake, кто-то вообще каких-то неведомых тварей. Скажешь, разнообразие - это хорошо? Возможно. Но не всегда. В данном случае - нет. Поскольку и разнообразие весьма условное. "Есть несколько популярных билд систем, которые поддерживаются. Но в них херовый синтаксис. Есть получше, но они никому не нужны. Выбирай".
- Модули. Добавлены только сейчас. Даже STL еще не использует. Может, к 30 году будет популярнее. В других языках это уже стандарт, повсеместный. Я не хочу ждать еще десятилетие. А ты?
- Несколько основных компиляторов. Три. На разных платформах рулит один из них (gcc на линуксе, clang на андроиде/маке/айоси, msvc на винде). Каждый работает немного по-разному, каждый имеет свой список поддержек стандарта, каждый не реализовал все его фишки. Apple Clang и Clang - разные вещи с разной поддержкой фичей.
У нас приложение под все три десктопа и оба мобайла. Использовать C++20 пока нельзя по разным причинам из-за компиляторов. Мне надоела такая дикая разрозненность и невозможность использовать последние фичи здесь и сейчас.
- Документация. У плюсов её фактически нет. Есть стандарт. И кучка сайтов, где её пытаются собрать. Но это не доки от разработчиков языка, и не Rust Book.
- Отсутствие пакетного менеджера. Это боль. У всех популярных языков есть. Кроме C/C++. Конечно, имеются разнообразные попытки. Но они не являются стандартом. Должно соблюдаться простое правило: "твоей либы нет в репе? твоей либы нет", но опять же, хаос.
- Множество способов сделать по-разному одну операцию. И в самом коде, и вне него. Хорошо ли это? Это дает выбор. Но когда каждый делает по-своему — это не благо возможности выбора, а неразбериха.
- Море разных стайл гайдов. Посмотри список дефолт в clang format, например. Каждая компания, каждый проект пишут по-своему. В Расте есть дефолт форматтер, и это хорошо.Только компания может создать нормальную инфраструктуру
И если эта компания нормальная, действительно любит опенсорс, выпускает опенсорс язык, то почему бы не получать все блага?Чисто поржать: сравни запрос в Гугле "C++ lang download" и "Rust lang download".
Сразу всё осознается, не правда ли?
> Вот не дочитал коменты до конца, но в очередной раз увидел и задался вопросом.
> Отчего сообщество rust такое токсичное?Сказанное тобою, на мой взгляд, подразумевает, что ты увидел представителей сообщества rust в комментах? Ты можешь указать хотя бы на один коммент, который, на твой взгляд, был оставлен представителем этого самого сообщества rust?
(не считая этого моего коммента -- про этот коммент я и так знаю, что он оставлен сектантом rust'а)
Это каким боком две доп инструкции при вызове malloc роняют произовдительность на 0.02%? По-моему, это на 200% (была одна инструкция, стало три)
malloc это не одна, а десятки или даже сотни инструкций.
В аду сатана pешил пpоведать, как у него людям "живется".
Hу, зашел в одну комнату - там мpак, чеpти издеваются
над людьми, в дpугую заходит - там на костpе всех жаpят,
кpики вокpуг... Заглядывает в тpетью - а там тишина, на
столе стоит комп, pядом ящик
пива, сидит программист, чего-то пpогpаммиpует. Сатана чеpтям:
- Ребята, у нас же здесь ад! Что это вообще такое?
- А!.. Дык он на C пишет!:-Е}