Опубликован релиз проекта Memsafe, реализующего механизм безопасной работы со ссылочными типами и динамической памятью в коде на языке С++. Защита может быть добавлена без нарушения обратной совместимости со старым С++ кодом. Проект оформлен в виде одного заголовочного файла memsafe.h и плагина для компилятора Clang. Код распространяется под лицензией LGPL 2.1...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62830
Прикольно, С++ превращается в уродливый Rust. Т.е. судя по вайбу (последним новостям), диды таки признали что это реально проблема, а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык.Ну кто бы сомневался, все заминусованые местными хомячками давно об этом говорили. Грядётъ.
>а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык.Всё это требует зарплату и не одну (по времени), и не на одного.
Мораль: работает - не трогай, иначе сам за всё ответишь.
> работает - не трогайНо ведь не работает же. Особенно когда потрогал (а трогать надо - движение это жизнь) и сразу словил кучу CVE.
Как только что то на уровне С и С++ пишешь на рс, везде ансейф
ансейф по определению архитектура памяти твоей
У меня совсем другой опыт
>Мораль: работает - не трогайЭто самое опасное заблуждение, которые засело в головах. Потому что оно консервирует техдолг. Вот так оно "работает не трогали" 30 лет, а потом новое поколение хватается за голову как этот кусок копролита развивать и масштабировать. В условиях, что половина стека передохла, ага.
"Работает - не трожь" - это мораль русских сисадминов. Некоторые его переносят на другие сферы жизни. Тот Дед перевёл его в плоскость программирования. Ещё, слышал такую мораль - "Если хочешь нормально провести выходные, то не настраивай сервер в Пятницу". Это всё скорее не заблуждение, а национальная русская мораль.
т.е в сша в банковской сфере сисадминами и программистами сидят сплошь русские по национальности ?)
Не нужно путать системного администратора с эникеем.Опять во всем русские виноваты?
> не настраивай сервер в ПятницуИ?
( Вы "теоретик бизнеса"? )
При чем тут мораль. Если сервер настроен и работает, то не надо его трогать, это логично.
Если после трогания сервер может простаивать, это убытки для бизнеса.
Я периодически слышу критику принципа "работает не трогай". Критикуют этот принцип люди неопытные и некомпетентные, но очень сильно желающие себя проявить. Заканчивается это простоем серверов.
Должны быть выстроены процессы с zero-down-time и прочим. Но куда до этого некомпитентным выскочкам. А евли вам страшно править уязвимости, то это конечно показывает опытность, да.
"Zero-down-time" - это очень дорогое удовольствие. Даже для очень солидных контор целесообразнее предупреждать клиентов о проведении работ (а для этого заранее внести в договор пункт о допустимом даунтайме), чем тратиться обеспечение настоящего "zero-down-time".
Но куда там высококомпетентному эксперту опеннета до каких-то презренных денежных вопросов.
С одной стороны правильно. Если все отлажено и нормально работает и не нужно в ближайшее время ничего улучшать и дыры исправлять, то да. В другом случае, как раз нужно трогать сервер и что надо менять и перенастраивать. Но только чтобы не было простоя нужно подходить к серверу с умом и определенными знаниями. Ну и перед этим все изменения нужно сначала на тестовом сервере проверить, а потом уже в прод
А потом тебе служба безопасности даёт ссылку на CVE кака раз на твою старую версию и ты в панике поднимаешь версию или увольняешься. Разве не так?
"Mitigation"? Не, не слышали.
Когда публикуется CVE, затрагивающая установленный в хозяйстве софт, надо не в панике версию поднимать, а спокойно прикинуть, какие последствия эта CVE может иметь, и как их минимизировать или исключить какими-то вспомогательными мерами. А там и обновлённая версия в репах подоспеет, проверенная (кроме прочего) на отсутствие регрессий.
Бизнес считает риски, в том числе того, что сервак упадет, а значит, либо у бизнеса есть резервные серваки, которые спокойно можно модернизировать, либо это не бизнес, а лавочники.
и что ты предлагаешь? ты хоть раз сократил свой техдолг?
Это не заблуждение. Это - реалии для сложных систем. Если оно долго проработало и потеряло актуальность - делается ТЗ, готовится документация и делается НОВЫЙ продукт согласно новым реалиям. И им постепенно, с допиливаниями, заменяют старый.
А не лезут кривыми руками в старый, с кучей подпорок и который местами хз как вообще работает
>Вот так оно "работает не трогали" 30 лет, а потом новое поколение хватается за голову..Ну так напиши свое новое, хорошее.. Если есть за что хвататься конечно ))
Название Rust говорит само за себя - ржавление. Смысл языка в том, чтобы саботировать чужую работу через сообщество переписывателей и свидетелей безопасности в язычке без спецификации.
Они бы ещё гнилью назвали свой проект, было бы точнее.
> Название Rust говорит само за себя - ржавление.Удивительно, но хейтерочки не знают, что Rust назван в честь очень живучих грибков.
> Смысл языка в том, чтобы саботировать чужую работу через сообщество
> переписывателей и свидетелей безопасности в язычке без спецификации.Смысл языка в том, чтобы показать тyпopылым дидам, что за 50 лет модели угроз изменились и из омнокоду не место в этом мире. А в перерывах можно их натыкать мордочкой в очередную CVE.
> Они бы ещё гнилью назвали свой проект, было бы точнее.
Тебя Иван покусал?
Может его с работы выгнали, а вместо него взяли зумера с растом. Вот и борется так, как лучше всего умеет - в интернете.
>что за 50 лет модели угроз изменились и из омнокодуДиды как раз и придумали аппаратную защиту памяти- атрибутная (контекстная) защита.Да да, Эльбрус мягко говоря позаимствовал идею с Барроза.А тут разработчики риск-5 обнаружил что патенты то истекли и внедрили защиту.У арм подгорело и в арм64 они тоже внедрили такую же защиту.А вот x64 грустно, приходится изобретать Раст,Яву и. Net.
Эльбрус смог, Арм смог, а Интел и АМД не смогли. Пришлось изобрести Раст и Яву.Не знаю, кто твой дилер, но товар у него отборный, это прям заметно.
> Не знаю, кто твой дилер, но товар у него отборный, это прям
> заметно.Вы читали что такое атрибутная защита ? У x64 весит совместимость с x32 , вдобавок 1 бит уже зарезервирован за noexec .Откуда им взять биты для атрибутов для контекстной защиты,это нужно ломать совместимость.У арм64 для мобильника сделали специальный режим работы -для памяти зарезервировано 48 бит, остальные биты для атрибутов.Совместимость не сломана,т.к софта на 64 бита памяти не много (практически нет) , суперкомпьютер фуджитсу пожалуй единственный кто использует 64 бита для памяти.Мипс5 аналогично ,в разработке,софта не много.Эльбрус использует аппаратный финт ушами- аппаратные ЕСС коды коррекции ошибок памяти используется для атрибутов памяти,но это решение запатентовано, придется покупать лицензию :-) Так что не зря Интел спонсирует Раст,не все так просто.
> Вы читали что такое атрибутная защита ?Нет. И, судя по описанию, в ближайшее время не прочитаю.
> Так что не зря Интел спонсирует Раст,не все так просто.
Мой тейк вот к этому относится.
Интел много чего поддерживает, и притянуть за уши можно любую теорию заговора.
Не читал, но осуждаю.. Ну, обычное дела, да.
> У арм64 для мобильника сделали специальный режим работы -для памяти зарезервировано 48 бит, остальные биты для атрибутов.у армов памперс ненадёжный оказался
Атака позволяет определить содержимое атрибутов - ну определил а дальше то что?
Все равно сложность атаки для хакера очень возрастает, особенно с рандомизацией памяти.
> ну определил а дальше то что?https://github.com/compsec-snu/tiktag?tab=readme-ov-file#rea...
>> ну определил а дальше то что?
> https://github.com/compsec-snu/tiktag?tab=readme-ov-file#rea...Перевод описания
Расширение тегов памяти ARM (MTE) - это функция ARMv8.5-A, предназначенная для смягчения атак с повреждением памяти. Гаджет TikTag ломает MTE, утекая теги MTE посредством спекулятивного выполнения. Когда гаджеты TikTag выполняются спекулятивно, состояние кэша различается в зависимости от того, вызывают ли гаджеты ошибку проверки тегов или нет. Следовательно, наблюдая за состояниями кэша, можно утечь результаты проверки тегов, не создавая никаких исключений. Гаджеты были эффективны как для Pixel 8, так и для Pixel 8 pro, которые являются первым оборудованием с официальной поддержкой MTE.Нечего нового ,в PDF я все прочел.
Утечка тегов,определил ты тип тега ну - а ДАЛЬШЕ ТО ЧТО ? Что с этими тегами ты делать собираешься,солить ? Да атака типа Спектра,плохо,но теги не секретная информация.
> Утечка тегов,определил ты тип тега ну - а ДАЛЬШЕ ТО ЧТО ? Что с этими тегами ты делать собираешься,солить ?ты под веществами чтоли ссылки открываешь
> We crafted a TikTag-v2 gadget in JavaScript that can leak the tag of the entire renderer process memory space. Utilizing the leaked tag, this PoC exploits the recent heap overflow vulnerability CVE-2023-5217 in the libvpx library to bypass the MTE protection and trigger the memory corruption.
>CVE-2023-5217 in the libvpx library to bypass the MTE protectionНе все правильно тегированно,софт нужно дополнительно адаптировать.Нашли слабо адаптированную библиотеку,всего лишь один тег на весь процесс- знали что в ней есть ошибка,вызвали функцию с переполнением,так обошли защиту. Нечего нового пока не вижу .Бит noexec тоже не панацеей оказался,научились обходить,но уже крутиться приходиться.
> Эльбрус смог, Арм смог, а Интел и АМД не смогли. Пришлось изобрести Раст и Яву.примерно так да
https://arxiv.org/abs/2203.04117
ну и скорей всего на практике кроме эльбруса ни у кого аппаратная защита не работает из-за спекуляций. Видимо смекнули что попали в просак и нагнули программистов - пусть ипутся переписывают на ослином языке
> https://arxiv.org/abs/2203.04117
> ну и скорей всего на практике кроме эльбруса ни у кого аппаратная
> защита не работает из-за спекуляций. Видимо смекнули что попали в просак
> и нагнули программистов - пусть ипутся переписывают на ослином языкеКакие затейники. Это многое объясняет. Т.е. вся проблема в hardware от Intel/AMD.
Хруст - похоже какое-то временное промежуточное решение.
А Винду по-тихоньку отвязывают от x86-64.
Откуда берутся сектанты верующие в святой эльбрус/байкал?И как это должно помогать от переполнений буфера, когда у тебя юзерспейс аллокатор выделяет память большими кусками, и софт/железо по итогу никак не отличает одну аллокацию от другой?
"Байкалы" это действительно просто mips/arm/risc5, где железо ничего не отличает.А вот на "святых эльбрусах" есть теги в памяти (лежат вместе с битами ecc) и 128-битные указатели (включают размер буфера на который они указывают), а железо всё это проверяет.
Поэтому в безопасном режиме на e2k буфер действительно переполнить нельзя.
> Поэтому в безопасном режимеКлючевое слово. А теперь вопрос сколько програм в этом режиме собираются и работают (Ах, да: https://github.com/mbarashkov/e2k-protected-mode-patches/blo...), и какой оверхед в рантайме за собой несёт (Я лишь знаю что без protected mode указатели в 2 раза меньше)
И зачем нести этот оверхед, если с Rust у тебя все эти проверки могут пройти на этапе компиляции/явным образом и гарантированно в рантайме, при этом без привязки к железу?
Я не знаю как оно у эльбруса, однако я знаю что тот же CHERI не особо полезен с Rust, это железо было специально заточено для языков которые не способны сами спасти от дыр.
И даже там в безопасном софте у тебя зачастую дублируются проверки в железе и в софте, потому что в большинстве случаев тебе нужно самому обработать потенциальное переполнение, а не делать чтобы софт слепо падал.
Компиляторы вроде Rust способны свою проверку границ убрать если могут доказать что выход за пределы невозможен, а вот в железе эта проверка всегда будет, пускай со спекуляцией она и может быть дешевле.
> А теперь вопрос сколько програм в этом режиме собираются и работаютсмешной какой - а сколько на раст написано?
> И зачем нести этот оверхед, если с Rust у тебя все эти проверки могут пройти на этапе компиляции/явным образом и гарантированно в рантайме, при этом без привязки к железу?
затем чтобы не переписывать то что работает а просто пересобрать. Проверки в рантайме всё равно нужны потому что железо ты проверить не сможешь, или ты уже отключил MMU и IOMMU на своих серверах - с растом же безопасно. В отличии от раста аппаратные защиты не снижают производительность.
CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п.Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п).
В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;)
> И зачем нести этот оверхед, если...
Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности.
Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти.
Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п).А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное.
Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки.Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность.
Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI.
Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы.
Что касается Rust, то при всем моём уважении, там есть что улучшить/допеределать.
Нужно что-то более удобное для объектных подходов и менее птичье по набору соседствующих букв.
CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п.Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п).
В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;)
> И зачем нести этот оверхед, если...
Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности.
Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти.
Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п).А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное.
Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки.Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность.
Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI.
Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы.
Что касается Rust, то при всем моём уважении, там есть что улучшить/допеределать.
Нужно что-то более удобное для объектных подходов и менее птичье по набору соседствующих букв.
> "Байкалы" это действительно просто mips/arm/risc5, где железо ничего не отличает.RISC-V MTE
В 2023 году "Байкал Электроникс" обещали (https://russianelectronics.ru/2023-10-20-baikal-electronics/...) показать ЦПУ с ядром RISC-V в прошлом году. Обещанного ждут три года, но могу поспорить то MTE там не будет, даже не пахнет в перспективе.Делать ЦПУ уровня микроконтроллера за год совсем не сложно, даже не понятно почему не вышло. Скорее всего у Байкала проблемы просто с тиражом, ибо отечественные фабрики накрыл медным тазом еще аж Чубайс.
А вот ЦПУ конкурирующий хотя-бы с ТВГИ.431281.023 придется дизайнить чуть подольше, глядишь к 2028 испекут (с отставанием в 10 лет от Эльбрусов). Но с учетом того что патенты на многие ключевые моменты всё еще действуют и то что Байкал и Ядро ранее занимались лего-дизайном, а не реальной разработкой ядер, то вряд-ли получиться что-то конкурирующее c T-Head.
Но кто я такой чтобы меня слушать, не то чтобы верить.Ну и IMHO, RISC-V это стеклянные бусы для папуасов, но очень удобно для попила/осваивания бюджета на НИОКР. Как говорится, правильный попил -- дело благородное (https://www.kommersant.ru/doc/7552143) ;)
Государственных денег я бы не давал, а предложил-бы господам выпустить акции/облигации для желающих встрять и/или неистово инженерить.
Но опять-таки, кто я такой чтобы меня слушать, не то чтобы верить.Жаль что второй раз наступаем на грабли EC-ЭВМ, что один разу уже похоронило отечественную отрасль на полвека.
> и IMHO, RISC-V это стеклянные бусы для папуасов, но очень удобно для попила/осваивания бюджета наДа практически везде так - где импортозамещение.Вон монитор тому пример- прилепили микросхему которая нахрен не нужна.
Беда в том что количество все решает _ а у нас нет такого рынка для сбыта, соответственно бусы будут дороже импортных аналогов в любом раскладе.А главное нет стимула для развития - вон снимут санкции и опять принемся всё закупать со страшной силой.
> Беда в том что количество все решает _ а у нас нет
> такого рынка для сбыта"Нет рынка" означает "рынок захвачен". То есть, с точки зрения экономики, идёт война (и free RISC-V -- обычный демпинг) и следует говорить "как вернуть утраченные позиций?"
> соответственно бусы будут дороже импортных аналогов в
> любом раскладе.А главное нет стимула для развития - вон снимут санкции
> и опять принемся всё закупать со страшной силой.Расклад сейчас такой, что инвесторы говорят "нет людей". Людей нет, поскольку одни уехали, а другие собирают из кубиков Лего, не шибко напрягая извилину. Получается замкнутый круг.
>И как это должно помогать от переполнений буфера, когда у тебя юзерспейс аллокаторПрочли бы учебник-вопросов не возникло бы. Cтр 98
Архитектура «Эльбрус» защищает контекст программного модуля, образо-
ванный объектами, которые допускается в нем использовать согласно пра-
вилам языка программирования. Это делается путем организации доступа
к низкоуровневому представлению объекта в памяти или регистрах через
«проходную» его дескриптора — служебного слова, содержащего ссылку
и информацию об объекте, соответствующую его типу. Доступ возможен
только через дескриптор. Аппаратные операции создания и использования
дескрипторов специализированы таким образом, что не оставляют возмож-
ности непосредственного воздействия на объект.
Scip
Ни длина, ни тип числовых данных архитектурно не различимы.
В отличие от числовых данных, нечисловые данные строго типизируются.
Прежде всего гарантируется целостность составных форматов (двойное
слово и квадро), что предполагает следующее:
все фрагменты должны иметь тип, соответствующий формату;
ScipВ общем в дискрипторе размер и тип буфера.Попытка записи за пределы буфера-Гитлер капут,срабатывание защиты.
Никто почему-то не вспоминает о том, что грибы это ПАРАЗИТИРУЮЩИЙ организм
>Удивительно, но хейтерочки не знают, что Rust назван в честь очень живучих грибков.Но то, что автор перед началом его "проектирования" наелся грибочков, это точно.
> Название Rust говорит само за себя - ржавление.Все намного хуже! Цитата с википедии про Rust:
Rust began as a personal project in 2006 by Mozilla employee Graydon Hoare.[16] Hoare has stated that Rust was named for the group of fungi that are "over-engineered for survival".Т.е. это инфекционное паразитическое заболевание, во как!
Любопытно, откуда автор узнал о тех грибах? Например, мне рассказывали, как в европах в голодные годы народ вкушал заражённый спорыньей хлеб, после чего принимался бурлить и устраивать революции.
> а на раст перейти нельзя из-заИз-за отсутствия lts версий rustc. И не надо заливать про эндианы. Они фиксируют не компилятор, а язык.
За lts можно брать версию, которую в дебиане или сентоси заплесневели.
> За lts можно брать версию, которую в дебиане или сентоси заплесневели.При этом всегда найдется какой-нибудь bcachefs'ный тул который им не компилится. Не могут хайпующие хипстики - в LTS. Не их это.
То что у тебя bcachefs не компилируется из-за того что сишники не могут в lts это печально, но причём тут Раст?
У bcachefs утилиты для управления на Rust написаны, и они требуют последнюю версию компилятора.Что однако любому сишному пакету мешает зависеть от более новых версий других пакетов - история умалчивает.
> То что у тебя bcachefs не компилируется из-за того что сишники не
> могут в lts это печально, но причём тут Раст?При том что не компилится у этого этого добра - кусок на хрусте, системным тулчейном хруста из дебиана. За что оно и вылетело из Stable версии, если кто пропустил новости.
Так что как видите точка зрения - подперта конкретными фактами по части хрустиков.
Т.е ты хочешь брать не-LTS пакет, и собирать его LTS компилятором?Гнилому компилятору гнилые пакеты, у тебя проблемы ещё с любыми другими пакетами могут быть аналогичные.
> Гнилому компилятору гнилые пакетыС чего вдруг? Потому что ты так сказал?
Посмотри какие версии gcc новое ядро linux требует.
Собирать на всех поддерживаемых дистрибутивах установленными в дистрибутив компиляторами - базовое требование для системных проектов.
То что система встройки rust в ядро всегда требует последнюю версию компилятора - это огромная проблема! И она не решаема.
> То что система встройки rust в ядро всегда требует последнюю версию компилятора
> - это огромная проблема! И она не решаема.Утилиты bcachefs не могут требовать более новую версию Rust чем существовала на момент их (утилит) выхода.
То что мейнтейнеры решают выборочно обновлять пакеты - это огромная проблема! И она решаема, нужно только захотеть.
> Т.е ты хочешь брать не-LTS пакет, и собирать его LTS компилятором?
> Гнилому компилятору гнилые пакеты, у тебя проблемы ещё с любыми другими пакетами
> могут быть аналогичные.В итоге bcachefs'овские тулсы из дебиана просто выперли с аргументом "их хруст не билдуется системным тулчейном хруста". Все что надо знать о хрусте vs LTS, в общем то.
И да, C++ таким маразом не страдает.
Нужно эквивалентное поведение программы, а не lts и подобные костыли.
Минусы/плюсы ничего не значат.Не проблема это когда там чото с памятью не то.
Проблема это когда совсем кода нет, или когда нужного функционала нет.
А когда код есть, но бывает падает - это уже то с чем можно жить, но конечно хочется совсем без этого.Насчёт легаси кода - забавный подход с навешиванием ярлыков.
Ну типа щас уберём резко весь "легаси" на С и крестах - и что останется? - НИЧЕГО.
Даже хруст не чем будет собрать и где запускать.
Так что это не легаси а меинстрим получается по факту.
> но бывает падает - это уже то с чем можно житьЖить, когда падает, можно. С современным подходом к отказоустойчивости это как раз не проблема.
Проблема когда не падает, а даёт доступ к памяти из-за уязвимости.
И что тебе уже сломали или украли?
Не надо называть проблемой то, что существует только на бумажке.
Лично меня, за последние несколько лет, – нет, не ломали (или я об этом не знаю, хех).Сервера с которыми я имею дела, прямо или опосредованно, – да. Начиная от дешёвых хостингов, которые ломают через дыры в кривых CMS, и заканчивая серверами в зоне business critical и выше, где атаки уже точечно-целевые.
Было бы оно на бумаге, все бы на этот Раст и безопасность чихать хотели бы.
> Лично меня, за последние несколько лет, – нет, не ломали (или я
> об этом не знаю, хех).
> Сервера с которыми я имею дела, прямо или опосредованно, – да. Начиная
> от дешёвых хостингов, которые ломают через дыры в кривых CMS, и
> заканчивая серверами в зоне business critical и выше, где атаки уже
> точечно-целевые.
> Было бы оно на бумаге, все бы на этот Раст и безопасность
> чихать хотели бы.Обычно 99% дыр прикрыты огромным количеством софта по безопасности. Всякие нюхачи типа SNORT, антивирусы, систем блокировки трафика по портам, по контексту и т.д.
Если ты идешь на самый дешевый сервис с какого перепугу ты ищешь в этом виноватого? За защиту своей системы ты сам несешь ответственность.
Теперь про CMS и их взломы. Это будущее Ржи.. Факты взлома CMS - это яркий показатель что даже использование языков которые ВООБЩЕ С ПАМЯТЬЮ не работают и т.д. не гарантирует тебе абсолютно никакой безопасности.
У моего клиента кучу всего переломали. Use-after-free в сишном демоне, рут шелл, ддос-ферма. Благо мониторинг работает, заметили что начали ноды из сети пропадать и исходящий трафик трендить в лимит, обломали кому-то праздник. Но трафик ещё полбеды, с провайдером всегда можно договориться. Месяц разгребали получившийся в результате бардак, кого-то из отпуска вызвали, каким-то кастомерам сроки сорвали, и у них что-то следом посыпалось, в целом нервная атмосфера — вот это реально дорого вышло. То, что вас весь бизнес — это лендинг на народе.ру и сеточка 192.168.0.0/24 не значит, что у всех так.
Бизнесс это про риск манагемент.
В остальном нынче легко софт запереть так чтобы оно ничего не могло сделать кроме того для чего создано.
>>Use-after-free в сишном демонерасскажите как вы это определили
Реплей трафика и пару часов в gdb. Спроси лучше как атакующие это определили, это куда интереснее.
> У моего клиента кучу всего переломали. Use-after-free в сишном демоне, рут шелл,
> ддос-ферма. Благо мониторинг работает, заметили что начали ноды из сети пропадать
> и исходящий трафик трендить в лимит, обломали кому-то праздник. Но трафик
> ещё полбеды, с провайдером всегда можно договориться. Месяц разгребали получившийся в
> результате бардак, кого-то из отпуска вызвали, каким-то кастомерам сроки сорвали, и
> у них что-то следом посыпалось, в целом нервная атмосфера — вот
> это реально дорого вышло. То, что вас весь бизнес — это
> лендинг на народе.ру и сеточка 192.168.0.0/24 не значит, что у всех
> так.Дай догадаюсь - А да, руководство решило что компания слишком много платит профессионалу/ам..
> Дай догадаюсь - А да, руководство решило что компания слишком много платит профессионалу/ам..Нет, с чего ты взял? Обычная компания — свой продукт, медианные зарплаты, соцпакет, wfh.
> Жить, когда падает, можно. С современным подходом к отказоустойчивости это как раз не проблема.тебе там выше написали про аппаратную защиту памяти но ты прочитать не сумел, а с ней ничего переписывать не надо
Это не так часто становилось реальной проблемой.
Вы знаете, дорогие друзья по растосрачу, я пришёл к выводу что секрет успеха сижки в том, что там правильно поставлен приоритет в отличие от плюсов и прочих брейнфаков.
Поясню: брейнфаки приоритетят безопасность, мол а как же так, а что если ты не туда присунешь переменную, или там вообще за границу уедешь. Это как бы факт. Их это волнует, и вот они городят свой забор с защитой от всего что попало.
Сижка же говорит: да и хрен с ним. И фокусируется на том чтобы быть простой и прозрачной без лишних вывертов.
Результат: весь код на сижке и с багами. Брейнфакеры крякают, но мы то знаем
> я пришёл к выводу что секрет успеха сижки в том, что там правильно поставлен приоритетЕго сделали таким, что даже умственно отсталые могут как-то писать?
> Сижка же говорит: да и хрен с ним.
Логично. Если язык овняный, то и код должен соответствовать.
> быть простой и прозрачной без лишних вывертов.
Хахаха, такое мог сказать только тот, кто не читал "стандарт" (тот самый, от котого плевался сам создатель языка)
> Результат: весь код на сижке и с багами.
Сишку выкинули уже из практически всех ниш.
Остались самые копролитные легаси проекты.> Брейнфакеры крякают, но мы то знаем
Знаете что? Что пришете овнокод? Ну так это все знают))
Что сейчас народу важна корректность кода? Ну так сейчас всех дыряшечников начинают потихоньку уринированными тряпками гонять.
Почему уже 2 разных(!!) проекта как заставить дидовый кодище работать хоть немного лучше.
Продолжай убеждать себя
Вообще знаешь что, пашел нахрен с бубунты тогда если у тебя не работает
> Поясню: брейнфаки приоритетят безопасность, мол а как же так, а что если ты не туда присунешь переменную, или там вообще за границу уедешь. Это как бы факт. Их это волнует, и вот они городят свой забор с защитой от всего что попало.Ты написал все правильно, только переменные перепутал (что не удивительно).
Растоманы не беспокоются о безопасности, им это даёт язык, можно писать код, не задумываясь о границах итераторов и прочей мелочи, как в примере из статьи. Язык кривой код не скомпилирует.А вот сишники и их братья плюсовики вынуждены думать через строчку: стрельнёт / не стрельнёт. Но стреляет у всех, даже у профи, потому что мы человеки и быть всегда на сто процентов в фокусе невозможно.
Это называется оптимальное решение.
Хотя не следует забывать, что могут измениться и сам критерий оптимальности, и выставляемые ограничения.
Для своего времени Си оказался хорош. Может ли он продолжать оставаться хорош? Вопрос.
Ведь меняется и структура рынка, а тут уже могут включаться и вовсе "нетехнические" параметры.ЗЫ Жаль, что создателя Раста когда-то перл укусил.
Секрет в том, что дефективные манагеры не шарят в разработке, если код спроектирован правильно, если гвоздями прибиты требования безопасности и стиля написания кода - что С, что Rust даст нормальный результат. А вот, если мозг отключен, тестирования нет и код записки сатаны, тогда результат будет дерьмовый, что на С, что на Rust.
Значение идиомы "бородатая шутка" почти забыто, я так посмотрю...
Ничего не имею против ржавого, но эти растофанатикотролли, 99% которых за всю жизнь и строчки кода не написали "доставляют" и вызывают желание только закрыть тред предварительно пожелав сажи во все поля.
Напомню, 10 лет назад я писал что проще в c++ добавить гарантии.
На что растоманы отвечали что это невозможно. Теперь растоманы в очередной раз переобулись. Нагрянуло.
> а на раст перейти нельзя из-за кучи легаси кода и лени учить новый язык.Ну а также можете предложить ООПный язык как плюсы, только с этой безопасной работой с памятью? Rust скажем так не совсем таков.
Эта "кучка легаси кода" всего то 70~98% из всего х86 кода, сущая мелочь ага)
Для начала пусть сделают правило чтобы нельзя было значение optional использовать без проверки
Да какой optional, окстись! Тут на одних только указателях два новых стандарта наваять можно.
Точнее – нужно.
То есть вся ценность rust свелась к одному заголовочному файлу для C++? Или я что-то не так понял?
Всё правильно понял. А ещё любители ржавчины почему-то думают, что если весь код завернуть в unsafe, этот ансейф будет безопаснее сишного. Если язык позволяет что-то сломать, это обязательно произойдёт.
Поэтому Rust небезопасен by design, потому что позволяет небезопасные вещи. Подобно Джаве, которая позволяет делать небезопасные и некорректные вещи (линковка с C/C++ через JNI, платформозависимая арифметика), язык Rust со временем будет также признан "недостаточно безопасным", а затем придумают ещё один язык, в этот раз точно супербезопасный, мамой клянусь! И будут на него переписывать небезопасные программы на небезопасном Расте.
> А ещё любители ржавчины почему-то думают, что если весь код завернуть в unsafe, этот ансейф будет безопаснее сишного.У ржавых просто сделано по человечески "вот мускорка, мы туда складываем всякие стремные штуки. А в остальном доме мусорить плохо".
А у С/С++ - просто овно размазано ровным слоем по всей квартире.> Если язык позволяет что-то сломать, это обязательно произойдёт.
Надеюсь что ты живешь в многоэтажке с лестницами без перил, ездишь на авто без подушек безопасности и используешь только неизолированные провода))
> Поэтому Rust небезопасен by design, потому что позволяет небезопасные вещи.
Твое мнение очень важно для нас.
Пойду поем.> язык Rust со временем будет также признан "недостаточно безопасным", а затем придумают ещё один язык,
Было бы неплохо, лет так через 20.
вы ещё забыли про динозвров, метеориты, извощиков разных типов и может ещё чтото...
вот честно, надоели все ваши эти аналогии
> вы ещё забыли про динозвров, метеориты, извощиков разных типов и может ещё чтото...зато не забыл про CVE и новости раз в пару недель "в дырявом коде нашли пачку уязвимостей"
> вот честно, надоели все ваши эти аналогии
не нравится - не читайте)
> Надеюсь что ты живешь в многоэтажке с лестницами без перил, ездишь на авто без подушек безопасности и используешь только неизолированные провода))Раст не создает перила, он лишь не позволяет их пересекать. То есть растоманы и плюсовики ходят по одним и тем же лестницам, разница лишь в том, что первым администрация здания доверяет меньше, чем вторым.
>> Надеюсь что ты живешь в многоэтажке с лестницами без перил, ездишь на авто без подушек безопасности и используешь только неизолированные провода))
> Раст не создает перила, он лишь не позволяет их пересекать.Еще как создает.
Чтобы их пересечь тебе придется сделать осознанное действие - написать unsafe.
Это примерно как в зравом уме и твёрдой памяти эти самые перила перепрыгнуть.> То есть растоманы и плюсовики ходят по одним и тем же лестницам, разница лишь в том, что первым администрация здания доверяет меньше, чем вторым.
Абсолютно неверная аналогия.
У плюсовиков здание построено с падающими кусками перекрытий. Но это не страшно, зато его построили быстро.
Вместо розеток просто 2 провода: ну и что, что регулярно каких-то неудачников поджаривает, но зато никаких проблем с совместимостью!
И вообще предупреждающие знаки это какое-то смузихлебное нововведение.
Ага, заголовочный файл включи, команды компилятору передай, С++20 перейди. Сколько дидов этим будет реально заморачиваться? А в расте это есть из коробки и по-умолчанию - тем он и хорош.
А диды будут пользоваться растом? Так пишите будто бы да.
А молодняк будет обязательно соблюдать все требования раста? Или всё-таки будет вилять и пытаться обойти ограничения? Это пока растом интересуются более-менее понимающие люди, код нормальный. А как пойдёт в массы (если), то массы будут писать овнокод с обходом ограничений раста, лишь бы запускалось.
> о массы будут писать овнокод с обходом ограничений раста, лишь бы запускалось.Фишка в том, что обход ограничений виден за версту!
И ты можешь просто прогрепать сколько строк внутри ансефа.
Жду спортивное программирование на расте на голом unsafe, без единого safe.
> А молодняк будет обязательно соблюдать все требования раста? Или всё-таки будет вилять и пытаться обойти ограничения?Сильно не повиляешь – даже ансейф не делает из раста cишку. А в сейф и того подавно.
А за ансейф, не к месту, на код ревью, по сусалам надают – вредные привычки надо искоренять.
> код ревьюЧел, оно далеко не везде есть. Даже в крупных компаниях.
Именно этот момент и выпадает из пропаганды Раста (слово пропаганда без осуждения, пусть будет промоущен).
Можно придумать сколь угодно совершенный формальный язык, и все равно с этой стороны интерфейса с ним будет работать несовершенный (по определению) писатель на этом языке.
молодняк не будет пользоваться растом из-за сложности вхождения. им подавай питон или джаваскрипт
Дважаскрипт уж точно лучше раста, но в ядро Линукс его не пропихивают!
> Дважаскрипт уж точно лучше растаУж точно - нет, не лучше.
Ну вообще - там, где надо (хинт - не в opensouce, этим и впрямь покласть) на уровне проекта вполне себе энфорсится.
> То есть вся ценность rust свелась к одному заголовочному файлу для C++?Нет. "реализована на базе сильных и слабых ссылок"
Т.е. то что в расте реализовано в компайлтайме, в плюсах будет проверяться в рантайме.
С соответствующими накладными расходами на исполнения.
Нет. Тут другая модель управления память. Не как в Rust, когда компилятор отслеживает единственного владельца сильной за счет "заимствования", а стандартный shared_ptr, которых может быть несколько.Вот эти "несколько" и отслеживаются плагином во время компиляции, чтобы не было циклических и зависших ссылок. А в рантайме проверяется только счетчик владений в shared_ptr с атомарными инкрементами и декрементами.
> А в рантайме проверяется только счетчик владений в shared_ptr
> с атомарными инкрементами и декрементами.Этого вполне достаточно для замедления программы :)
Гугел и не только уже экспериментировали со всякими miracle_ptr и оно реально тормозило.
Знаменитое zero-cost из C++: оно как бы zero, но не совсем.— У нас есть классы и оно zero-cost! (vtable не считается)
— У нас есть умные указатели и они zero-cost! (игнорируем счётчик ссылок)— А как получить настоящий zero-cost?
— Это к С, мальчик. Иди, не мешай дядям.
TANSTAAFL. Zero-cost не бывает в принципе. Да, ваш любимый раст - он в 2 раза медленнее, чем C++.
> Да, ваш любимый раст - он в 2 раза медленнее, чем C++Ага, раст делает проверки и оптимизации в компайл тайме, а С++ – в рантайме, поэтому С++ быстрее.
Л – логика.
вообще-то, например, при получении, условно, элементов массива в while-цикле с инкрементом, растц вполне себе рантайм проверку бахнет.
и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку.
> и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку.Теорема Чёрча — Россера
Как вынести условие цикла за*) цикл?*) Для других, шибко умных анонимов: за оператор while, а не тело.
> Как вынести условие цикла за*) цикл?кхммм, как это условие выхода из цикла вынести за цикл, переформулируйте или вы имеете ввиду goto-акробатику?
>> Как вынести условие цикла за*) цикл?
> кхммм, как это условие выхода из цикла вынести за цикл, переформулируйте или
> вы имеете ввиду goto-акробатику?Я имею ввиду, что задачу можно решить в частных случаях, не для всех while.
Если это всё померить, то окажется, что проверка предсказывается и не сказывается на производительности.
> вообще-то, например, при получении, условно, элементов массива в while-цикле с инкрементом, растц вполне себе рантайм проверку бахнет.
> и код будет медленне такого же на С, до момента, пока в С-версии не добавят проверку.Ну да, всего делов-то - вместо использования итератора удалять гланды^W^W "написать как в сишке" и вот тогда ...
Есть обходные решения для этого:https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-ru...
> Да, ваш любимый раст - он в 2 раза медленнее, чем C++.Где пруфы?
>> Да, ваш любимый раст - он в 2 раза медленнее, чем C++.
> Где пруфы?Вот:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
просто нужно брать правильные программы для сравнения!
А если по потреблению памяти(больше == лучше), то вообще любая плюсанутая вариация уделывает этот ваш сраст в 2-5 раз!
> Вот:
> https://benchmarksgame-team.pages.debian.net/benchmarksgame/...Первый же пример fannkuch-redux
secs cpu secs mem
* C++ g++ #6 3.33 13.12 5,800
* Rust #6 3.81 15.06 3,985> просто нужно брать правильные программы для сравнения!
Ага) Ты прям выбрал, так выбрал)
> А если по потреблению памяти(больше == лучше), то вообще любая плюсанутая вариация уделывает этот ваш сраст в 2-5 раз!
Ты имел про то что оно жрет больше?
> он в 2 раза медленнее
> * C++ g++ #6 3.33 13.12 5,800
> * Rust #6 3.81 15.06 3,985
>> просто нужно брать правильные программы для сравнения!
> Ага) Ты прям выбрал, так выбрал)
> 3.33
> 3.81
> 2 разаНу ты прям метаном^W всем показал, так показал!
Че там кстати с другими тестами?
* Rust #7 0.78 2.00 157,442
C++ g++ #6 1.14 2.25 285,639
====
* Rust #7 0.78 2.00 157,442
C++ g++ #6 1.14 2.25 285,639"нещитаица" или "этодругое"?
> Ну ты прям метаном^W всем показал, так показал!Продолжаешь обделываться?
> Че там кстати с другими тестами?
> * Rust #7 0.78 2.00 157,442
> C++ g++ #6 1.14 2.25 285,639Давай разделим 1.14 на 0.78 и получим... два не получаем.
Все фанатики такие убого безграмотные или ты просто такой униКал?> "нещитаица" или "этодругое"?
Что другое?
Ты тут пуукнул про "в 2 раза медленнее", потом выпукал "в 2-5 раз".
А теперь обделался и пытаешь слиться.
std::unique_ptr<…> - zero-cost.
struct{…}, class{…} без виртуальных функций - zero-cost. А там где нужны виртуальные функции, ты и на С не сможешь без индирект-call.
> std::unique_ptr<…> - zero-cost.Нет, ABI запрещает передавать его через регистры, что не даёт ему быть zero-cost.
При добавлении нестандартного [[clang::trivial_abi]] "Google has measured performance improvements of up to 1.6% on some large server macrobenchmarks, and a small reduction in binary sizes" - https://libcxx.llvm.org/DesignDocs/UniquePtrTrivialAbi.html
>> std::unique_ptr<…> - zero-cost.
> Нет, ABI запрещает передавать его через регистры, что не даёт ему быть
> zero-cost.Не вижу запрета
3.2.3 Parameter Passing
After the argument values have been computed, they are placed either in regis-
ters or pushed on the stack. The way how values are passed is described in the
following sections.Definitions We first define a number of classes to classify arguments. The
classes are corresponding to AMD64 register classes and defined as:INTEGER This class consists of integral types that fit into one of the general
purpose registers.
...
NO_CLASS This class is used as initializer in the algorithms. It will be used for
padding and empty structures and unions.
...The classification of aggregate (structures and arrays) and union types works
as follows:1. If the size of an object is larger than eight eightbytes, or it contains un-
aligned fields, it has class MEMORY.2. If a C++ object is non-trivial for the purpose of calls, as specified in the
C++ ABI, it is passed by invisible reference (the object is replaced in the
parameter list by a pointer that has class INTEGER).3. If the size of the aggregate exceeds a single eightbyte, each is classified
separately. Each eightbyte gets initialized to class NO_CLASS.4. Each field of an object is classified recursively so that always two fields are
considered. The resulting class is calculated according to the classes of the
fields in the eightbyte:
(a) If both classes are equal, this is the resulting class.
(b) If one of the classes is NO_CLASS, the resulting class is the other
class.
(c) If one of the classes is MEMORY, the result is the MEMORY class.
(d) If one of the classes is INTEGER, the result is the INTEGER.
(e) If one of the classes is X87, X87UP, COMPLEX_X87 class, MEM-
ORY is used as class.
(f) Otherwise class SSE is used.> При добавлении нестандартного [[clang::trivial_abi]] "Google has measured performance
> improvements of up to 1.6% on some large server macrobenchmarks, and
> a small reduction in binary sizes" - https://libcxx.llvm.org/DesignDocs/UniquePtrTrivialAbi.htmlИ что?
> И что?И ничего.
> Не вижу запрета
И что?
Если хочется что-то сказать или уточнить по поводу накладных расходов у std::unique_ptr, то сказал бы.
Если не хочется, то стоило ли начинать?
>> Не вижу запрета
> И что?Поскольку заявление "ABI запрещает передавать его через регистры" не подтверждено требованием из System V Application Binary Interface AMD64 Architecture Processor Supplement, считаю его ложным.
> Если хочется что-то сказать или уточнить по поводу накладных расходов у std::unique_ptr,
> то сказал бы.Я уточнил, когда делал свою реализацию std::unique_ptr до принятия стандарта, Clang тогда не существовал. Сейчас мне любопытно одно: где прописан запрет?
> Если не хочется, то стоило ли начинать?
Советую не начинать.
>> И что?
> И ничего.Действительно.
Я не папа римский и даже свой unique_ptr не писал. Могу сослаться на P2028[1] и спросить, в чём тогда он ошибается? И почему не стали передавать через регистры?[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20... :
The largest example we have for issues with the calling convention comes from passing unique_ptr. For the Itanium ABI (used on Linux systems, among others), any type with a destructor that is passed by value must be passed in memory: the address held in this unique_ptr must be written out to memory (and then potentially re-fetched in the calling function), rather than passed in registers as it would be for a raw T*.
Had implementers and the specifiers of the Itanium ABI agreed to specialize the handling of unique_ptr<T> passed by value, it could perhaps be no more expensive than a raw T*. That wasn’t done before unique_ptr<T> was introduced, and thus now it would be an ABI break to change the calling convention without updating all callers and callees in sync.
В стандарте Си++ (ссылкой на ISO/IEC 9899) "запрещено" записывается как "shall not".4. Conformance
1 In this International Standard, ‘‘shall’’ is to be interpreted as a requirement on an
implementation or on a program; conversely, ‘‘shall not’’ is to be interpreted as a
prohibition."Не стали" и "запрещено" несколько разные вещи.
Есть требование передавать ссылку, "If a C++ object is non-trivial for the purpose of calls". Например, когда вызывается экспортируемая модулем (.so) функция, надо иметь возможность вызвать деструктор. Если же вызываемая функция связывается с другими в один модуль, то оптимизатору не запрещено поступать как ему заблагорассудится, вплоть до встраивания.
> В стандарте Си++ (ссылкой на ISO/IEC 9899) "запрещено" записывается как "shall not".Запрещает ABI, не стандарт C++. В стандарте C++ нет такого понятия, как ABI.
> "Не стали" и "запрещено" несколько разные вещи.
Не стали - в реализациях стандартной библиотеки.
Запрещено - в ABI (в Itanium ABI и в "менее формальных ABI", возникающих из нежелания ломать совместимость между версиями).
Лежит непотревоженным - стандарт C++.> Если же вызываемая функция связывается с другими в один модуль, то оптимизатору не запрещено поступать как ему заблагорассудится, вплоть до встраивания.
Но это ведь связано не с определением "non-trivial for..."[1], а с исчезновением необходимости придерживаться определённого ABI.
[1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivial :
non-trivial for the purposes of callsA type is considered non-trivial for the purposes of calls if:
it has a non-trivial copy constructor, move constructor, or destructor, or
all of its copy and move constructors are deleted.
>> В стандарте Си++ (ссылкой на ISO/IEC 9899) "запрещено" записывается как "shall not".
> Запрещает ABI, не стандарт C++. В стандарте C++ нет такого понятия, как
> ABI.Мы уже выяснили, что запрета нет.
>> "Не стали" и "запрещено" несколько разные вещи.
> Не стали - в реализациях стандартной библиотеки.
> Запрещено - в ABI (в Itanium ABI и в "менее формальных ABI",Нет цитаты в подтверждение. Повторяться о разнице shall и shall not смысла не вижу, когда кому-то очень хочется выдать первое за второе.
> Мы уже выяснили, что запрета нет.Мы, аноним двеститридцатый, выяснили, что запрет находится в Itanium C++ ABI.
Лингвистические экзерсисы из стандарта языка пусть останутся в стандарте языка.
А к "неформальным ABI" экзерсисы вообще не притянуть, они же неформальные.> Нет цитаты в подтверждение.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.[1](это, конечно, шутка, но чем посторонний RFC хуже постороннего стандарта?)
> разнице shall и shall not
"the caller must ... pass that temporary by reference" - нормальная фраза
"the caller shall ... pass that temporary by reference" - годится
"the caller shall not ... not pass that temporary by reference" - так мог бы сказать ГэндальфКстати, кто несёт ответственность за нарушение "shall not" в стандартах C(++)? Административную или уголовную?
"A goto statement shall not jump...", но goto не обладает правоспособностью. И если никого не оштрафуют, какой же это запрет? И разве штраф был бы настоящим запретом, а не банальным ценником на нежелательное действие?
>> Мы уже выяснили, что запрета нет.
> Мы, аноним двеститридцатый, выяснили, что запрет находится в Itanium C++ ABI.Чушь. 230-й аноним выдал вот это "Могу сослаться на P2028[1] и спросить, в чём тогда он ошибается?"
>> разнице shall и shall not
> "the caller must ... pass that temporary by reference" - нормальная фраза
> "the caller shall ... pass that temporary by reference" - годится
> "the caller shall not ... not pass that temporary by reference" -
> так мог бы сказать ГэндальфНо сказал 230-й Аноним. С чем его и поздравляю.
Пример притянут за уши. При передаче std::unique_ptr<…>, как аргумент функции "по значению", вы ещё и передаёте владение объектом. Что отличается от передачи raw-pointer. Как говорится - "чем пользуетесь, за то и платите".
Уши растут из заявления "std::unique_ptr<…> - zero-cost".> Как говорится - "чем пользуетесь, за то и платите".
Это первая часть смысла zero-overhead abstraction по-страуструповски.
А вот вторая, которая нарушается: "What you do use, you couldn’t hand-code any better".
Вот из-за таких демагогов и гибнут проекты. Главное победить на словах перед начальством. А то что из-за профессиональной близорукости накрылся проект - они даже осознать это не в состоянии. Потому что, всегда были правы в болтовне. Ни одного факта не привёл, всё свелось к пересказу чужих мыслей, пусть даже и не до конца их понимая.
"Простите, часовню тоже я развалил?"*
Мы одну фразу обсуждаем: "std::unique_ptr<…> - zero-cost".
И нафига брать выражение Струструпа, вкладывать в него свой другой смысл и из-за этого заламывать руки?
* СтрауструпаИ где демагогия-то? n00by не согласен с тем, что ограничение берётся из ABI. А ты хочешь сказать, что ограничения с соответствующим оверхедом вовсе не существует? Или хочешь постараться ничего однозначного не говорить?
Я хочу сказать, что некорректно сравнивать два семантически разных вызова функций.
void foo(bar* ptr); // не определено, кто владеет ptr
И
void foo(std::unique_ptr<bar> ptr); // передача владения внутрь функции
Решают две разные задачи.
Если вернуться к
> 50. Карлос Сношайтилис:
> — У нас есть классы и оно zero-cost! (vtable не считается)
> — У нас есть умные указатели и они zero-cost! (игнорируем счётчик ссылок)То я с ним тоже не согласен и ещё написал в другой ветке про девиртуализацию.
Но если перейти к "std::unique_ptr<…> - zero-cost", то это не zero-cost, потому что мы платим за неоптимальность по сравнению с другой возможной реализацией владеющего указателя.
Эта другая реализация ломает обратную совместимость (тоже ABI, в общем-то) и вроде бы немного нарушает стандарт и спрятана за _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI в одном компиляторе.
Не согласен.
std::unique_ptr<X> - по размеру такой же как и X*.
std::unique_ptr<X> - по скорости доступа к объекту X, такой же, как и X*.
Когда вы применяете move() семантику, то используете свойство которым не обладает raw-pointer. И здесь, возможно, придётся немножко доплатить.
> Когда вы применяете move() семантику, то используете свойство которым не обладает raw-pointer.В C# можно найти много новых свойств по сравнению с ассемблером или Cи (и при необходимости опуститься хоть до CIL). Если их на этом основании объявить zero-cost, то нас не поймут, а то и поколотят и правильно сделают.
Страуструп этот тонкий момент чувствовал и говорил не только про "не используешь - не платишь", но и про "используешь - имеешь оптимальную реализацию". Поэтому с "придётся немножко доплатить" надо считаться.
"No run-time overhead compared to good hand-crafted code (the zero-overhead principle)"[1]
Большой оверхед на владеющие указатели недопустим, поэтому дальше идёт рассказ про, внезапно, gsl::owner[2]. "Lack of resources" упоминается среди причин для его использования[3].
Новые возможности классов по сравнению с сишными структурами - это ещё не повод иметь объекты только на куче и передавать только по ссылке (а ведь это подходит под "не используешь - не платишь", если сишные структуры тоже оставить)[4].
[1] https://www.stroustrup.com/resource-model.pdf#page=4
[2] https://www.stroustrup.com/resource-model.pdf#page=7
[3] https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...
[4] https://www.stroustrup.com/ETAPS-corrected-draft.pdf#page=4
> если сишные структуры тоже оставить* Тоже оставить существовать параллельно с новинками.
** Текст под [2] и [4] - вольный пересказ тех страниц.
Не имея мозгов, и на ассемблере можно написать программу медленнее Питона. Никто не предлагает делать std::move() для std::unique_ptr<> несколько миллионов раз в секунду. А тем кто так делает, надо сменить профессию. Основные операции с указателями - разыменование и сравнение с чем-либо. Здесь оверхэда не будет.
Каждая языковая конструкция имеет свою область применения. Использовать везде shared_ptr<X> вместо X*, а потом кричать про оверхэд - непрофессионально. Использовать виртуальные функции везде, вместо обычных - тоже показатель отсутствия архитектуры в программе.
"используешь - имеешь оптимальную реализацию" - здесь сразу встаёт вопрос о критериях оптимальности. По каким параметрам оцениваем оптимальность? Не всегда производительность является решающим параметром.
"... это ещё не повод иметь объекты только на куче и передавать только по ссылке" - про это вообще не понял к чему?
И вообще - очень много общих слов, хотя и красивых. Хотелось бы конкретики, с примерами кода.
> "используешь - имеешь оптимальную реализацию" - здесь сразу встаёт вопрос о критериях
> оптимальности. По каким параметрам оцениваем оптимальность? Не всегда производительность
> является решающим параметром.Ну а какой оверхед может быть в рантайме? Память, производительность. И так как std::unique_ptr - инструмент общего назначения, то ориентироваться на общие, усреднённые потребности.
> "... это ещё не повод иметь объекты только на куче и передавать
> только по ссылке" - про это вообще не понял к чему?Страуструповский взгляд на допустимые накладные расходы. Со страницы по ссылке.
"In general, C++ implementations obey the zero-overhead principle ... Compare this with a more typical layout from a “pure object-oriented language” where each user-defined object is allocated separately on the heap and accessed through a reference".> И вообще - очень много общих слов, хотя и красивых.
В его возрасте ожидаемо. Да и обсуждаемый принцип (zero-cost, он же zero-overhead) - он такой, общий и красивый.
> Хотелось бы конкретики, с примерами кода.
Эта просьба подразумевает, что разработчики кланга с их _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI - не очень умные люди, как и пользователи этой опции.
Либо зачем-то предлагает поторговаться насчёт точной величины того ~1% производительностиИ то, и другое сомнительно.
>> Хотелось бы конкретики, с примерами кода.
> Эта просьба подразумевает, что разработчики кланга с их _LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI
> - не очень умные люди, как и пользователи этой опции.
> Либо зачем-то предлагает поторговаться насчёт точной величины того ~1% производительностиОни очень умные, а потому не воюют открыто с GCC и его оборюзгшей библиотекой. 1% это такая мелочь в 2к25, но они целенаправленно добиваются своего.
Вообще-то ничто не мешает в C ручками прикрутить vtable, чтобы полиморфизм симитировать.
И если при этом не будет автоматической девиртуализации по возможности, то тогда плюсы становятся negative-cost!
> И если при этом не будет автоматической девиртуализации по возможности, то тогда плюсы становятся negative-cost!Не будет.
Эмуляция ООП на Си работает медленнее. Ибо все проверки в рантайм и нет оптимизаций.
Заголовочный файл + плагин для компилятора.> ... но после проверки исходного кода плагин можно вообще не использовать, поскольку он только анализирует AST, но не вносит в него никаких исправлений.
Костыль не принимается, только новая нога.
Аналогия изначально хорошая, поскольку при попытке приживить новую ногу всю жизнь придётся пользоваться имунноподавляющими лекарствами. Костыль или протез подобного не требуют.
Можно взять ногу от близнеца.
Близнеца можно сделать клонированием, желательно заранее, уже при рождении человека (типо страховка такая).
Но их у ц++ уже и так 20, куда уж больше?
Походу особо одаренным, просто религия не позволяет использовать и/или С++ и/или Rust. Хз, в чём проблема то? - жесть!
Проблема-то проста. Изучи и то и другое на норм уровень и не вырви мозгом
Достаточно знать программирование на «норм» уровне, и язык программирования перестанет иметь такое большое значение и становится всего лишь средством достижения цели. Да, какие-то языки лучше подходят для решения каких-то задач в каких-то доменах, какие-то меньше. К каким-то душа лежит, а к каким-то не лежит. На каких-то писать можно только за зарплату, а на каких-то ещё и для души. Но это сиюминутные мелочи. Скилл — он совсем в другой плоскости лежит.
Это бесполезно объяснять удушенным Яндекс практикумом "мега питон синьор помидор".
А зачем им это объяснять? Пусть себе воюют. Где бы их для этого обособить, что бы остальным мозг не клевали - вот вопрос.
Жму вам всем руки, товарищи адекваты. Здоровья.
Их и обособили, здесь на опеннете.
Считать что хороший программист на С/С++ освоит новый язык в совершенстве за две недели/месяц/год - это профнепригодность!
А в совершенстве что-то знать не только невозможно, но и не нужно. Нужно конкретные прикладные задачи решать на приемлимом уровне. Для хорошего программиста изучение языка на уровне, соответствующем уровню проекта не является сложной задачей. Ещё раз повторю: скилл лежит совершенно в иной плоскости. Не в плоскости языков программирования, тулчейнов, редакторов, ДЕ, ОС, или клавиатурных раскладок.
Приемлемый уровень - это "середнячок". Этого точно достаточно чтобы писать качественный и безопасный код? Да... это явно выходит за рамки профнепригодности.
> Приемлемый уровень - это "середнячок". Этого точно достаточно чтобы писать качественный и безопасный код?Точно, доказано и показано на практике всей софтверной индустрией, год от года. Практически весь код на этой планете написан посредственными программистами. Даже если ты гений один на миллион, в одном только NYC вас таких восемь, а нужно — от силы два, и оба уже трудоустроены. Задач столько нет, чтобы всех гениев занять.
Был бы гений, а задача найдется. Да и речь шла не о них...
> Считать что хороший программист на С/С++ освоит новый язык в совершенстве за
> две недели/месяц/год - это профнепригодность!"на С/С++" уже само по себе маркер. ;)
> "на С/С++" уже само по себе маркер. ;)А какая разница? (с)
Что первое дырявое поделие с кучей типичных проблем, что второе, судя по нытью Страуструпа)
Учитывая все ВНЕЗАПНО появившиеся попытки "а давайте сделаем ЯП хоть немного безопаснее" то это начали осознавать и другие люди.
Путаешь теплое с мягким. Не ЯП хотат сделать безопасным, а хотят добавить инструменты, которые будут отрезать указанную функциональность для указанных артефактов программы.А ЯП как был так и останется.
Не совсем понятно, о чём идёт речь?
Кто более-менее знает языки, тот не пишет "на С/С++".
Львиная доля всего программного обеспечения написано на С/С++, а вы озвучивает подобную ерунду. Как себя чувствуете?
Когда приходится собеседовать кандидатов, всегда ищу и рекомендую к найму тех, которые любят не языки и дистрибутивы, а тех которые умеют программировать и админить системы. Языкам и особенностям дистрибутивов научить можно довольно легко. Научить думать — крайне тяжело. Научить видеть лес за деревьями — практически невозможно.
> Когда приходится собеседовать кандидатов, всегда ищу и рекомендую к найму тех, которые любят не языки и дистрибутивы,Почему же?
Если владение тем или иным дистрибутивом это отличный показатель.
Например если соискатель начинает рассказывать про слаку или диван - то понятно что это пердолик-нетакусик, который будет лепить костыли и для командной работы слабо пригоден.> а тех которые умеют программировать и
А как ты это проверишь)?
> админить системы.
Админиить можно научить даже камаку.
Тут особо мозги не нужны.> Языкам ... научить можно довольно легко.
На каком уровне?
Если на уровне "не сошлись типы - кастуй к void*" то да.
Но это не программирование, а халтура)
Собственно, программирование -- это когда берётся "маленький кусочек бытия", абстрагируются от деталей и записывают на понятном машине языке. В таком раскладе язык подбирается (в частном случае, создаётся) под задачу. Но иногда нужны и программисты на определённом языке, или нескольких. Как бы то ни было, знатоки "языка С/С++" к последним не относятся, так что в любом раскладе не очень годны.
>> Кто более-менее знает языки, тот не пишет "на С/С++".
> Львиная доля всего программного обеспечения написано на С/С++, а вы озвучивает подобную
> ерунду.Знаю ПО написанное на Си.
Знаю ПО написанное на Си++.
Знаю ПО написанное на Си и Си++.Хотелось бы увидеть ссылочку на "написано на С/С++".
> Как себя чувствуете?
Прекрасно чувствую. Но подозреваю, что вместо ссылки начнётся, как тут любят писать, "бред": во-первых, моё утверждение подменено левым (угу, кавычки несут смысл), во-вторых, "у кого что болит".
Где-нибудь, хоть словом обмолвился о том, что С/C++ - это один язык? Придумали подобную глупость, так еще и меня в этом обвинили...
> Где-нибудь, хоть словом обмолвился о том, что С/C++ - это один язык?Да, вот сейчас - и приписал мне.
> Придумали подобную глупость, так еще и меня в этом обвинили...
Ещё раз: угу, кавычки несут смысл. Странно, что приходится такое повторять "программисту".
Ваше предположение было мной опровергнуто. Вы считаете уместным повторяться?
> Ваше предположение было мной опровергнуто.Ещё раз моё утверждение:
Кто более-менее знает языки, тот не пишет "на С/С++".
Если у кого-то знание человеческих языков недостаточное, то: кавычки обозначают цитату. Если бы я хотел заявить, что знающий Си или Си++ не пишет на этих языках, я бы написал без кавычек (и без дробей).
> Вы считаете уместным повторяться?
Поскольку намёк не понят, объясняю: грамотный человек напишет вместо символа / что-то иное. Например, "писал [программы] на С и С++".
И повторяться я могу сколь угодно -- чем дольше не понимается моё объяснение, тем больше подтверждается исходное утверждение о любителях писать "С/С++".
Форточку открой.
Что и требовалось доказать.
> Что и требовалось доказать.Требовалось открыть форточку, а не доказывать что-либо. Но ты доказал, что не понимаешь смысла написанного. Впрочем, это было очевидно.
Раньше писали "ламер", при этом следовали нудные пояснения, что именно персонаж не понимает. Снежинки натренировались распознавать близость фиаско и принялись превентивно писать "душно". ;) Это слово точно такой же маркер, как "программирую на C/C++" и "программирую на JS/HTML/CSS/WYSIWYG".
>Снежинки натренировалисьА ты не обучаем.
Если я захочу научиться скрывать свою личность, то учиться буду не у персонажа "Никто" с Опеннет. ;)
Ты и есть никто с опеннета.
> Ещё раз моё утверждение:
> Кто более-менее знает языки, тот не пишет "на С/С++".Оценка языков может производится с разных точек зрения и по разными параметрами.
Соответственно классификация тоже будет очень разной.Например если кто-то говорит "я специализируюсь на ФП", то даже без уточнения можно, с высокой долей вероятности, предположить, что перед вами занудный тип, который будет рассказывать про монады и прочую лабуду от теоретиков.
Можно конечно брать во внимание что С и С++ это разные языки, со своими стандартами, преимуществами и недостатками...
А можно применить теорему г-на Эскобара и объединить их в один кластер "дырявые окаменелости из прошлого тысячелетия".В качестве пруфа приведу иллюстрацию из статьи [1] в блоге гугла
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...Что удивительно там С/С++ объединяют!
У меня есть большие сомнения, что инженеры гугла не знают отличий в этих сортах языков.
Скорее в обсуждаемой теме они не существенны.[1] https://security.googleblog.com/2021/04/rust-in-android-plat...
> Походу особо одаренным, просто религия не позволяет использовать и/или С++ и/или Rust.
> Хз, в чём проблема то? - жесть!Концептуально Rust сырой. Предположим написали уже гору софта, а расто-маны раз и очередной раз поменяли концептуальные основы языка, так как концепция просто не предусматривала какой-нибудь ВАЖНОЙ мелочи.
Тем более такое уже было. Понятны последствия?Рассказать чем закончилось это в прошлый раз? Именно после такого "финта ушами" - я пересмотрел вообще отношение к расту.
> Тем более такое уже было. Понятны последствия?После Rust 1.0? Когда и что это такое было?
>> Тем более такое уже было. Понятны последствия?
> После Rust 1.0? Когда и что это такое было?Так было или не было?
И какие гарантии у Ржи что такого не будет в дальнейшем? У С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными участниками.
В случае Ржи - толпа маргиналов.
MEMSAFE - очередной нестандартизированный костыль для плюсов. Крупным производителям ПО нужен язык, генерирующий быстрый код с минимальными затратами на отладку крупных проектов. И чтобы индусы были подешевле. Ну а вы продолжайте лениво ковырять сишечкой свой никому не нужный DIY, никому нет до этого дела
>>> Тем более такое уже было. Понятны последствия?
>> После Rust 1.0? Когда и что это такое было?
> Так было или не было?Ты скажи, ты же это заявление сделал. А официально у Rust сказано что ломающие изменения могут быть только в editions, новая версия компилятора будет компилировать код написанный под старый edition, и в одном проекте ты можешь смешивать пакеты написанные под разные editions.
https://github.com/rust-lang/rfcs/blob/master/text/2052-epoc...
В целом это не особо отличается от плюсовых стандартов, за тем исключением что Rust компилятор умеет все editions и строго их разделяет, а msvc/gcc/clang каждый имеет своё подмножество поддерживаемых, и иногда это не спасает от того что код перестаёт компилироваться при обновлении компилятора.
> И какие гарантии у Ржи что такого не будет в дальнейшем?
У Rust строгий, прозрачный, и демократичный RFC процесс, вся история развития языка в публичном доступе, по любому изменению ты можешь прочитать дискуссию, какие были альтернативы, и т.д.
> С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными
> участниками.Вот только по итогу эти серьёзные участники друг с другом спорят по поводу изменений стандартов и в итоге приходят к неприятным для всех компромиссам без возможности сообществу внести свои предложения, а GCC/LLVM эти стандарты читают как хотят, и половину предложенных стандартов не реализуют.
>[оверквотинг удален]
>> И какие гарантии у Ржи что такого не будет в дальнейшем?
> У Rust строгий, прозрачный, и демократичный RFC процесс, вся история развития языка
> в публичном доступе, по любому изменению ты можешь прочитать дискуссию, какие
> были альтернативы, и т.д.
>> С, С++ стандартизация есть и эта стандартизация работа комитета с серьезными
>> участниками.
> Вот только по итогу эти серьёзные участники друг с другом спорят по
> поводу изменений стандартов и в итоге приходят к неприятным для всех
> компромиссам без возможности сообществу внести свои предложения, а GCC/LLVM эти стандарты
> читают как хотят, и половину предложенных стандартов не реализуют.Этот бред даже комментировать желания нет.
>> а GCC/LLVM эти стандарты читают как хотят, и половину предложенных стандартов не реализуют.
> Этот бред даже комментировать желания нет.А зря. Потому что это не бред.
Просто открываешь
en.cppreference.com/w/cpp/compiler_support
и видишь что НИ ОДИН компилятор не реализует C++23 core language или C++23 library features полностью. Ни один, Карл!Вот такой классный стандарт, который к исполнению не обязателен.
"Стандарт — это просто свод указаний, а не жёстких законов." (с)
Занеси денег разработчикам, тогда будут тебе фичи, которые скажешь
В самом стандарте есть механизмы предусматривающие возможность реализации не всего стандарта. И так ДОЛЖНО быть.Когда контора начинает разработку - то производится анализ целевых платформ и формируется список функциональностей из стандартов которые можно использовать.
Других вариантов для множества компиляторов быть не может.
> В самом стандарте есть механизмы предусматривающие возможность реализации не всего стандарта.Значит это плохой стандарт.
> И так ДОЛЖНО быть.
Нет.
Например для того чтобы иметь право называться "компилятор языка АДА" нужно не только реализовать все что написано в спеке, но еще пройти примерно 1000 тестов (по принципу "хотя бы один завалил - на выход") и сертификацию.Вот такой подход для надежных систем, а не "тут мы делаем, а тут рыбу заворачиваем".
> Когда контора начинает разработку - то производится анализ целевых платформ и формируется список функциональностей из стандартов которые можно использовать.
А его кто-то проводил?
> Других вариантов для множества компиляторов быть не может.
Могут быть компиляторы которые написаны на разных языках или просто разными командами.
Но если они полностью реализуют стандарт и выдают одинаковый результат - то это хорошие компиляторы.
> Значит это плохой стандарт.С вашей точки зрения "плохой". А так - единственно возможный.
> Например для того чтобы иметь право называться "компилятор языка АДА"
И где теперь эта АДА?
> А его кто-то проводил?
Именно. Выдается список чего можно использовать, а чего нет.
Возможно не полный, но как только сборка одним из компиляторов нужной версии с нужными флагами обламывается - список пополняется.> Но если они полностью реализуют стандарт и выдают одинаковый результат - то это хорошие компиляторы.
Значит вы ничего в компиляторах не понимаете. Они принципиально не могут выдать одинаковый результат. Их результат может работать одинаково - плюс/минус. Но это уже совсем другая история.
> С вашей точки зрения "плохой". А так - единственно возможный.Что значит "единственно возможный"?
Я примел пример других вариантов.> И где теперь эта АДА?
Работает там куда дырявые плюсы не пустят)
> Значит вы ничего в компиляторах не понимаете. Они принципиально не могут выдать одинаковый результат.
Что значит не могут?
Я же не про побайтовую совместимость, а чтобы не было ситуации "скомпилировал шлангов - все работает, перешел на ГЦЦ - программу начала убивать юзеров".> Их результат может работать одинаково - плюс/минус. Но это уже совсем другая история.
Вот для результата "работать плюс-минус" это уже просто максимальная херня.
Про "переносимость" можно забыть.
Про корректность - тоже.
Прибиваем написанный код к определенной версии определенного компилятора и радуемся.
> Работает там куда дырявые плюсы не пустят)На которой пишут полтора землекопа?
> Что значит не могут?
Я же не про побайтовую совместимость, а чтобы не было ситуации "скомпилировал шлангов - все работает, перешел на ГЦЦ - программу начала убивать юзеров".
А временные характеристики на это повлиять не как не могут?
А если могут, то
> Я же не про побайтовую совместимость
Как разный бинарный код обеспечит одинаковые временные характеристик?
> Прибиваем написанный код к определенной версии определенного компилятора и радуемся. Именно так и делают разработчики rust и другого
В разработке нормальной же чем больше компиляторов и платформ используется в тестах - тем лучше будет код. Даже если реально он используется одним компилятором на одной платформе.
> На которой пишут полтора землекопа?Ой, а когда это количество погромистов стало признаком качества?
Если так судить, то пик развития программеров и яп это пыха и js.Зато наверное вся авиация летает на АДА. Самолеты конечно падают... но какой бы ужас творился если бы туда пустили плюсы или дыряшку!
> Ой, а когда это количество погромистов стало признаком качества?
> Если так судить, то пик развития программеров и яп это пыха и js.
> Зато наверное вся авиация летает на АДА. Самолеты конечно падают...Мало того что падали, так и падали именно из-за проблем с программным обеспечением.
И тут две причины.
1-я невыразительность языка, где тебя обязывают использовать то, что тебе не нужно.
2-я малой число программистов, а, следовательно, малая конкуренция среди них. И в итоге критически важным программным обеспечением занимаются люди к этому не пригодные.> но какой бы ужас творился если бы туда пустили плюсы или дыряшку!
В машинах работают. И требования в них намного жестче. С чего бы не работать в самолетах?
Веганская этичная горизонтальная сейфспейс разработка. Мы поняли
Ахаха!
Как забегали, как засуетились!
Теперь ждем гору различных и при том несовместимых решений для плюсов. В идеале - чтобы они еще конфликтовали друг с другом))
Вот это будет представление! Уже запасаюсь попкорном))
> Ахаха!
> Как забегали, как засуетились!
> Теперь ждем гору различных и при том несовместимых решений для плюсов. В
> идеале - чтобы они еще конфликтовали друг с другом))
> Вот это будет представление! Уже запасаюсь попкорном))Разнообразие решений приведет к выбору лучшего. Разнообразие это всегда отлично.
В отличии от кучки ржавых маргиналов с манией величия - нагнем всех, что продиктуем - то и будете пользвоать.
Противоречите сам себе. "Разнообразие это всегда отлично"?
> Противоречите сам себе. "Разнообразие это всегда отлично"?В прямом смысле. Каждый "разнообразный" отличен от остальных.
> Разнообразие решений приведет к выбору лучшего. Разнообразие это всегда отлично.Это от создателей "зачем в ядре 2 языка" и "да что эти, с крашенными волосами, себе позволяют!11" ?
Или ЭТО_ДРУГОЕ™ ?> В отличии от кучки ржавых маргиналов с манией величия - нагнем всех,
Хахахаха, сначала сделайте что-то нормально работающее, нагибаторы мамкины
> что продиктуем - то и будете пользвоать.
Пока шанс того, что дырявые языки выкинут из госконтрактов существенно больше.
Ты явно не понимаешь как устроена разработка
Напиши это со своего браузера, тогда поговорим.
Ой молодцы, пойду задоначу
Чтобы растовики отстали, но пользоваться все равно никто этим не будет.
А растовикам зачем приставать к плюсовикам?
Их и у себя хорошо кормят
да постоянно плюсы помоями поливают, а потом берут LLVM написанный на С++ и идут свои хелоувроты компилировать.
Помоями поливают Раст. "Кривой синтаксис", "ничего не написано", "безопасность с ансейф" и пр. Знакомо?
А растоманы пользуются трудами других людей и в ус не дуют.> потом берут LLVM написанный на С++
Если ты видишь в этом проблему или идеологическое несоответствие, то как же ты используешь ядро, написанное на С?
Или это другое?
> Или это другое?Конечно другое, мне нравится Си и считаю что весь системный софт, ОС и ядра с дровами должны быть написаны на нем.
Безопасность с ансейф называется безопасТность.
Процессору пофиг на чем ты свой хелловрот писал. Процессор умеет лишь в свой набор команд, слабо скормить процессору нативный си++ код? А что так?
Процессору то пофиг. Вот только машинные коды получаются не идентичные взасимости от того на каком ЯП был написан код, какие ключи оптимизации были использованы, какая версия компилятора и тд.
> А растовикам зачем приставать к плюсовикам?Хз. Петушатся, дыряшки им везде мерещатся...
Это новый MiraclePtr?
А что со старым, не взлетел?
Командная строка для запуска компилятора с плагином:
clang++ -std=c++20 -Xclang
Но где же гнутелла?))А вообще лучше трижды подумать чем завязываться на какое-то нестандартизированное поделие мутного васяна...
Плюсы не просто так стандартизировали, поэтому вот когда в стандарт добавят и реализуют в компиляторах - тогда и использовать можно будет.
Возможно, единственный адекватный комментатор под этой новостью.
Цены ему не было бы если бы он ещё дочитал до конца новости что это "нестандартизированное поделие" не влияет на генерируемый код.
То есть вы себя не включили в разряд адекватных? Бывает.
Да.
Ты собираешь компилятором gcc код.Собираешь его clang'ом с плагином.
И там и там соберётся. Как clang c плагином повлияет на собранный gcc код?
> Ты собираешь компилятором gcc код.
> Собираешь его clang'ом с плагином.О... т.е. вы предлагаете мне не просто тащить еще 100500Гб мусорного шланга в систему, но еще и заставляете использовать несвободный софт?
Ради чего? Чтобы пару CVE не сделать?Не дождетесь! Одной CVE больше, одной меньше. Переживете.
Какой из компиляторов является не свободным, gcc или Clang?
clang не свободный. По лицензии gcc нельзя посадить под замок
> Какой из компиляторов является не свободным, gcc или Clang?Clang - свободный.
А GCC - нет.
Они даже в свое время пытались провернуть "все что скомпиленно gcc заражается GPL".
Приколько конечно - твой код кто-то скомпилировал, теперь его надо открывать под гну-раком.
Их конечно знатно накормили и пришлось костылить GCC Runtime Library Exception.
Но работать с такими копирастами.. просто себя не уважать)
Битва сектантов.И то и другое инструмент. Разрабатывать можно на всех доступных. Не нравится лицензия в прод пускай сборку тем, что нравится.
Опять костыли. Куда то С++ пошел явно не туда после 11 и 14 версий. И чем дальше, тем сильнее не туда. Вместо учета пожеланий прикладных программистов все новшества исключительно для разработчиков самого С++ и его стандартной библиотеки, всё для себя любимых. Да и сама стандартная библиотека С++ какой то бред воспаленного ума, бред в горячке у Степанова. Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим. Вместо поддержки сети, например, зачем то эллиптические функции добавлены в стандартную библиотеку, хотя большинству программистов именно сеть нужна, а не эти функции. Даже поддержка строк сделана явно через ж@пу.
Не время думать о строках, указатели в опасности!
Могли бы, например, просто функции для прикладных задач из PHP в стандартную библиотеку Си++ перенести. Так нет же, маялись сплошным переусложнением ради переусложнения. На хабре эта тема уже поднималась, пришли к аналогичному выводу.Ладно, что есть то есть. К сожалению, пришлось на плюсах самому переизобретать некоторые вещи по итогу, свои классы обёртки писать, чтобы упростить Си++ до удобочитаемости скриптового языка для быстрого прототипирования.
Да, и строку тоже пришлось свою делать, т.к. пользоваться этим стандартным убожеством нет никакого желания. Получилось гораздо многофункциональнее, удобнее, проще. Я понимаю, велосипедостроение, но это реально - был шаг от отчаяния.
>Да, и строку тоже пришлось свою делать, т.к. пользоваться этим стандартным убожеством нет никакого желания. Получилось гораздо многофункциональнее, удобнее, проще.Голосом Каневского:
"Многофункциональнее, удобнее и проще конечно ни у кого не получилось" (c) Каждый велосипедист строк в плюсах обречен писать глючное подмножество стандартного решения, которое подмножество "не тормозит" из-за срезанных примерно всех углов квадратных колес велосипеда, и ломается примерно сразу в любых более других входных условиях, о которых велосипедист не подумал. А "проще" оно потому что максимально наивное.
>но это реально - был шаг от отчаяния.
"Не умеешь решить задачу в общем виде, пили велосипед для своего частного случая".
Наивно полагать, что "комитетчики" решили задачу в общем виде.
Они её решили просто безобразно.
Утверждать "решили в общем виде" можно на основании того, что basic_string вписываются к концепцию алгоритмов-итераторов STL. И голословно охаивать "можно" -- закон не запрещает.
Непереводимая игра слов?
Эксплуатация уязвимости парсеров с закольцованным входным буфером малого объёма.
Продолжайте наблюдение, мы с вами свяжемся.
Меня подобным не удивить - местный ботнет давно выдал все возможные тупые шаблоны.
> Меня подобным не удивить - местный ботнет давно выдал все возможные тупые
> шаблоны.Не скромничай, в этом плане ты вне конкуренции.
Ну ещё бы. И ты тоже будешь за мной повторять. ;)
Оно не туда после 97 чи 99 пошло.
>Оно не туда после 97 чи 99 пошло.Удачи сопровождать код из 90-х ("ехало UB через UB") в 2025-м, когда есть фичи стандартов 11++.
>>Оно не туда после 97 чи 99 пошло.
> Удачи сопровождать код из 90-х ("ехало UB через UB") в 2025-м, когда
> есть фичи стандартов 11++.Там было меньше UB чем в новых стандартах.
В старых возможностях часть UB убрали. Пересмотрели целевые архитектуры и опыт реализации.Так что в базовой версии языка стало меньше.
В новых, естественно, добавили. Ибо это необходимость для компилируемого переносимого языка.
Так что с сумма - стало больше.
>97 чи 99А такие были? Вот 98 и 03 точно были.
>>97 чи 99
> А такие были? Вот 98 и 03 точно были.Значит 98
> Опять костыли. Куда то С++ пошел явно не туда после 11 и
> 14 версий. И чем дальше, тем сильнее не туда. Вместо учета
> пожеланий прикладных программистов все новшества исключительно для разработчиков самого
> С++ и его стандартной библиотеки, всё для себя любимых. Да и
> сама стандартная библиотека С++ какой то бред воспаленного ума, бред в
> горячке у Степанова. Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим.
> Вместо поддержки сети, например, зачем то эллиптические функции добавлены в стандартную
> библиотеку, хотя большинству программистов именно сеть нужна, а не эти функции.
> Даже поддержка строк сделана явно через ж@пу.В ракурсе такого рассуждения - Раст это вообще сплошной костыль..
Каким образом сеть и эллиптические функции связаны?
Далее - эллиптические функции связаны с защитой/шифрованием данных и могут применяться как локально так и по сети.
Ну а сеть это сеть. Ее может на компе и не быть.Иногда серое вещество то включать надо.. Если оно конечно есть. Все в стандартных библиотеках сделано логично и нормально.
>Да и сама стандартная библиотека С++ какой то бред воспаленного ума, бред в горячке у Степанова.Знакомые песни неосиляторов, не написавших ничего примерно никогда. Степанов показал что есть альтернативы ООП и развесистые иерархии не нужны, остальное -- "разработка комитетом" (ТМ)
>Неудобная, с идиотской архитектурой, с синтаксисом явно нечеловеческим.
Это производная от того, что можно было сделать с т.з. обобщенного программирования на еще тех плюсах из 90-х, где привязки к GUI библиотекам делались несопровождабельной кашей из макросов. То-то "человеческий" синтаксис.
>Даже поддержка строк сделана явно через ж@пу.
Недалеким и потому самоуверенным велосипедистам все время кажется что проблема строк ограничена их частным случаем. А потом по кодовой базе разбросаны их велосипеды string2, string3, string_ng...
> Недалеким и потому самоуверенным велосипедистам все время кажется что проблема строк ограничена
> их частным случаем. А потом по кодовой базе разбросаны их велосипеды
> string2, string3, string_ng...Да отрок просто не догоняет что за 256 символами ASC-II есть еще UNICOD в различных инкарнациях для абсолютно непохожих языков типа японского и т.д.
Зачем тебе вообще строки, это такие же данные, как и другие.
Ну да, только ассемблер, только машинный код!
А реверсить его в читабельный вид и ревюить кто будет, телепаты в матрице?
Именно так. Добавляют нужное, но с невероятно медленной скоростью.
Вероятно это плата за стандартизацию, но непросто конечно с таким смириться.
Добавление в STL умных указателей больше 10-ти лет заняло.
Лямбды добавили, про потоки вспомнили, уже радость.
Корутины завезли хоть в каком-то виде, хотя явно неродные они в языке.
А ещё ведь есть строки с юникодом, сеть, дата и время, работа с базами данных...
Я естественно в курсе про boost и само-собой его использую по возможности, но когда возвращаешься к родным плюсам после питона или го...
Печаль в общем.
>большинству программистов именно сеть нужнаНе годиться в стандартную библиотеку. Возможны различные реализации.
>Даже поддержка строк сделана явно через жИзмененная строка это другой объект.
Прикладные программисты могут сами написать нужные библиотеки.
"на концепцию владения и заимствования из языка Rust"
Причем тут Ржа? Данные методики появились задолго до раста. В расте они были реализованы в концепции языка.
Я лет 20 назад баловался с похожими/идентичными идеями, но для себя использовать было лень :)
Методики задолго. А концепции взяли из раста как самые проработанные. ¯\_(ツ)_/¯
Сделали бы для начала инструмент валидации указателей на уровне стандартных библиотек. Все борются с UB, созданными толпой бывших питонистов - разработчиков компиляторов в погоне за лучшей оптимизацией. Не запрещено в стандарте - значит нужно оптимизировать - выкинув лишнее, выведем предупреждение если пользователь включит флаги а, б, с, ш. именно в этом порядке.
живой пример, питонисты пролобировали добавление в стандартные библиотеки функции strdup, которая автоматически делает realloc при вызове, но что будет если указатель был в стеке или статик, в питоне все работает - вносим в стандарт.
>>но что будет если указатель был в стеке или статика что будет если Вы пойдёте на красный свет? просто этого не делайте
не вызывайте free два раза подряд. ржавотики говорят, что проблема языка. прохожие из городов, где все время день, рредлагают не ходить на красный.
Си/C++ не исправить, поэтому и появилась куча других языков, например, odin и zig. Смиритесь и живите дальше.
> появилась куча других языковКак появилась, так и исчезла. С C/C++ был, есть и будет.
как и проблемы с памятью
неужели раст исчезнет первый?
Rust как был маргинальным языком программирования лет 10 назад (ныне на уровне Scratch-а судя по TIOBE) так и остался
Все языки исчезнут одновременно, как только ИИ заменит кожаных программистов. Ему проще сразу в машинных кодах будет.
В машинных кодах какой архитектуры? Тогда уж на JS, ну а чего, кросплатформенно же.
промежуточный код RISC-подобных виртуальных инструкций
У ИИ невозможно избавится от галюцинирования из-за самой сути машинного обучения.Вот когда будут разрабатывать сильный ИИ - тогда будет шанс. Но в эту сторону не то что бы шаг сделали - даже голову пока не повернули.
всё будет циклично, сильный ии найдёт лазейку для обучения у более тупого и сам станет тупым
> всё будет циклично, сильный ии найдёт лазейку для обучения у более тупого и сам станет тупымСильный ИИ проверяем. В нем все принятые решения должны быть обоснованы. И эти обоснования можно посмотреть. То есть сильный ИИ должен логически рассуждать.
Там нет месту такому обучению, которое используют сейчас.
Костыли, костыли, костыли....
К сожалению, костыли.
руки ноги - это костыли. мозги кстати тоже костыль не очень удачный )))
Железо памяти никому не позволит сделать её безопасной. Материя первична. Если все возможности наделать ошибок с памятью закрыть, то непременно понадобятся добавки или целые новые языки чтобы их опять открыть. Войнушка раст - плюсы чисто коммерческая. Оба языка синтаксически уродливы. Различие в том что плюсы стали уродом, а раст родился уродом. На этом фоне выиграл питон.
легко. каждому процессу по компу, тогда и памятью делиться не надо
А какое железо тогда нужно?
В rust хорошо, там изобретён блок unsafe. А в крестах как они собираются выкурчиваться? Тут же 100% кода как было unsafe, так и осталось, и любой коммит может как улучшить ситуацию, так и ухудшить
А здесь собираются дать возможность на каждый артефакт навесить что-то типа тега, управляющего функциональностью ему доступной. Помимо опций компиляции. Знает компилятор теги - проверит. Не знает - проигнорирует. Код в любом случае один и тот же.
В этом и проблема, что даже если проект и перейдёт на данный вариант, то никаких гарантий, что одним коммитом эту ситуацию не сломают - нет
Концепция "weak_ptr при захвате превращается в shared_ptr" - редкостное дермицо. Ибо если оригинальный shared_ptr освободит поток владельца, а в это время, weak_ptr будет захвачен, то это передаст владение объектом владельцу weak_ptr. Соответственно из его же потока будет вызван деструктор. По этому weak_ptr не настоящий слабый указать, а всего лишь возможность разорвать циклические ссылки. Как поверх этого дерьма можно ещё какую-то безопасность пытаться накрутить?
Вы мешаете в кучу теплое и кислое и правильно написали, что weak_ptr и shared_ptr, это только про циклические ссылки. И они не гарантируют корректную работу из разных потоков https://en.cppreference.com/w/cpp/memory/shared_ptr (так же как и попытка разименования nullptr является UB)Поэтому для работы из разных потоков нужно использовать другой класс со встроенной синхронизацией https://github.com/rsashka/memsafe/blob/main/memsafe.h#L416
Наконец-то! Можно выбрасывать Java, C#, Golang и начинать всё делать на C++. Это будет также легко и безопасно как на расте! Жду не дождусь. Сейчас вся индустрия повернёт вспять.
Ну и чего ты здесь опять распетушился со своим растом? Человек хотя бы попробовал - и это похвально. Возможно, кто-нибудь изучит его идеи и придумает что-то ещё более интересное и удобное. Это называется brainstorm.
>> Возможно, кто-нибудь изучит его идеи и придумает что-то ещё более интересное и удобное. Это называется brainstorm.Именно на это я и надеюсь, так как хоть и пишу на С++ очень давно, но знаю его только в необходимом мне объеме. А чтобы решать подобные глобальные задачи, требуется более глубокое понимание темы и стандартов, чем у меня.
Я немного обсуждал этот момент с Гербом Саттером и у него бОльший интерес вызвал способ обеспечения обратной совместимости с уже существующим С++ кодом, чем текущая реализация библиотеки (что естественно).
С Гербарием не пробовал обсудить?
Потому что ненужно. Реально лучше бы раст учили и вливались в современный мир, чем пытаться костыли вкорячивать для легаси технологий. Я вот смотрю как развивается Bevy - ветераны геймдева говорят, что движок *самый* удобный из всех существующих. И с каждой версией становится всё круче, семимильными шагами. Там будущее. Потому, что разрабатывать на нём быстрей и удобней. С момента, когда Карт начал чё-то ваять на коленке прошло 5 лет. Скоро выйдет версия 0.16, в которой рендерилка сравняется с самыми хорошими современными движками. Там будущее, а не в крестах этих гиблых.
Тяжеловесным крестам далеко до выразительных языков. И выборочное решение одной из многих проблем в безопасности не изменит этого
Разве С/C++ не являются одними из самых выразительных языков?
Нет, не является. В крестах нет очень большого количества возможностей, типа однострочной записи или конвееров.
this есть. Строй какие хочешь.
> но не требует разработки нового стандарта С++ (достаточно использовать уже существующий С++20).Так-то это уже не стандарт, а расширение языка.
Авторам:
Не соответствие имен переменных в примере и выводе плагина об ошибках
vec vs vect
x vs beg
y vs vect.end()
Примеры уже поправлены
Смысл этой возни с С++ малопонятен - новый код надо писать на Rust, для старого есть CHERI и достаточно пересобрать старый код без переписывания
Rust конкурент C, а не C++. Это не ООП язык программирования.
Когда речь идёт о миллиардных убытках наличие ООП волнует меньше всего - 4 дня на подготовку как в гугле и вперёд фигачить на расте отюда и до заката.
Rust между С и С++. Без unsafe ему было бы тяжело выжить.
Вот это вот, не умеющее by design в динамическую линковку без потери своей единственной плюшки - "конкурент C"? Честно - смешно.
Опять сказки про RISCV.Скопипащу про CHERI и оверхед:
CHERI во многом похож на безопасный режим Эльбруса. Но в e2k он появился в "железе" на ~20 лет раньше первых черновиков спеки CHERI. Кроме этого, в e2k было несколько редакций, включая поддержку private/public из C++ и т.п.
Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписывать (имеется в виду что смотрим только на релевантный код, а не на питон/bash/java и т.п).В этом, кстати, существенная часть мифа riscv -- на деле вы получаете что-то одно: простоту и дешевизну, производительность, безопасность, но никогда вместе. Особо забавно что часть "экспертов" подразумевают/считают/утверждают, что с CHERI будет также быстро как и без, что будет жрать почти столько-же питания, не сильно дороже, а еще и софт сразу будет совместим ;)
> И зачем нести этот оверхед, если...
Все всегда будут хотеть снизить накладные расходы и сэкономить на безопасности.
Там где безопасность желательна, но не обязательна, вполне логично не только по-полной идти во все тяжкие со спекулятивным выполнением, но даже выбрасывать защиту памяти.
Это действительно логично, ведь если у вас весь софт доверенный/отлаженный/проверенный и на условном java/rust, то оставшимися рисками можно пренебречь (например в играх и т.п).А вот там где требуются некие гарантии без аппаратной защиты не обойтись -- там как накладные расходы, так и стоимость соответствующей аппаратуры, принимаются как неизбежное.
Это просто ближе большинству сценариев в реальном мире, в том числе потому что невозможно всё нужное/используемое переписать на условных rust/java в разумные сроки.Суммарно рациональнее иметь язык обеспечивающий максимум статических проверок при компиляции и эффективно пользоваться аппаратурой для контроля в runtime, при этом аппаратура может быть как простой, так и обеспечивающей принудительную безопасность.
Проблема как языка С, так и "сишного" кода, особенно унаследованного, не в том что он подвержен общеизвестным типам багов, а в том что не позволяет задействовать контролирующую/проверяющую аппаратуру, т.е не совместим ни с безопасным режимом e2k, ни с CHERI.
Кстати, поэтому C также является одной из проблем отечественных Эльбрусов. Если помечтать что Linux был-бы написан на условном Rust, то Эльбрусы бы целиком могли работать в безопасном режиме (который тогда можно было-бы допилить/оптимизировать в нужную сторону), а в компиляторе не было-бы EDG-отравы.
> Основная проблема как безопасного режима Эльбруса, так и CHERI, не в оверхеде, а в том что 99% софта нужно переписыватьэто проблема Эльбрусов а не CHERI - достаточно ведь погуглить немного
> 10,000+ pre-built memory-safe packages
какое-то портирование нужно конечно но это не переписывание.
Основная проблема рассказываетелей мифов про проблемы riscv в том что они живут вчерашним днём где мифические Эльбрусы запретил злой Чубайс напрочь забывая что они просто неконкурентноспособны.
> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немногоДостаточно не погуглить, а почитать RTFM, чтобы сделать вывод что CHERI это "рисковый" аналог безопасного режима Эльбруса.
Соответственно, для CHERI нужно ровно такое-же "какое-то портирование" как и для Эльбрусов (очевидные и неизбежные различия на уровне инструкций и ассемблера опускаем).
Разница только в том "буржуи" вкладывают деньги/ресурсы/усилия в risc5, а "отечественные экспёрты" ноют потому-что пара неудачников на хабре что-то написали...
А последствия чубайсятины в развале школы и вышки, до состояния отсутствия стратегического мышления. Поэтому в головы и заходит любой хайп. Поэтому и вредители типа Александра Галицкого (отъявленный лжец и манипулятор, пойманный за язык неоднократно) считаются чуть-ли не пророками. И стеклянные бусы всё еще нравятся.
> А последствия чубайсятины в развале школы и вышки, до состояния отсутствия стратегического мышления.стратегическое мышление я так понимаю это отгородиться от мира и идти своим путём не смотря ни на что? Неудивительно что многим с вами не по пути.
> Поэтому и вредители типа Александра Галицкого
понятия не имею кто это, в идеале нужно разноплановое развитие как в Китае где есть всё - от свое архитектуры до корпусировки и переклеивания шильдиков из вафель брендов
> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немногоRTFM
"...although CheriABI and Benchmark ABI packages are currently considered experimental."Ну т.е. пакеты собираются, а вот работают только некоторые, и не во всех сценариях, и не всегда, и...
Зато можно по примеру упомянутого г-на Галицкого заявлять "это проблема Эльбрусов а не CHERI" и т.п.
Тем не менее, если CHERI просто выключить -- то будет чуть более безопасно ;)
> это проблема Эльбрусов а не CHERI - достаточно ведь погуглить немногоКак вам уже ответили (Вадим?) проблемы ровно теже, и cheribsd это пока скорее экспериментальный академический pet-проект.
Тем не менее, ВСЕ что там будет подготовлено/поправлено/допеределано/отлажено для CHERI подойдет и для Эльбрусов. Причем в 99% не потребует никаких дополнительных доработок, поэтому можно за месяц-два (а может и сильно меньше) превратить cheribsd в e2kbsd.ru
Короче, пусть пилят, нам пригодится ;)
> Причем в 99% не потребует никаких дополнительных доработок, поэтому можно за месяц-два (а может и сильно меньше) превратить cheribsd в e2kbsd.ruна CHERI десктоп с KDE уже год как работает - релиз 24.05, а e2kbsd.ru We’re having trouble finding that site. Похоже никому это не надо.
> на CHERI десктоп с KDE уже год как работает - релиз 24.05Ну вот зачем "своими словами" коверкать чужие новости (в которых и так всё максимально
"натянули").Во-первых, не на CHERI (RISCV), а на ARM Morello (который официально в статусе прототипа).
И всё это в статусе эксперимента.Причем не только потому что в природе нет CHERI-ядер пригодных для cheribsd и KDE, есть только (неприемлемо медленные) симуляторы на ПЛИС и low-end а-ля TPM.
Но и потому что на Morello можно есть слона по частям, а не портировать весь софт для совместимости с CheriABI.Во-вторых, там же очень "тонкий" момент насколько указатели реально контролируются в том коде, который выполняется.
Если по простому, то на e2k/cheri/morello внутри указателя также хранятся границы буфера, к которому можно обращаться. Поэтому для совместимости с унаследованным кодом эти границы могут просто устанавливаются на максимум, что почти отключает всю безопасность.
Поэтому всё сильно запутывается.
Сама возможность создавать "безграничные" указатели может быть как "сильно запрещена", так и "сильно разрешена" (вплоть до одной простой инструкции ЦПУ), а если это не запрещено то важно насколько много конкретное ПО использует эту возможность легального "обхода защиты".Это очень непростой момент, требующий продуманных компромиссов (что ARM и предложили в Morello). На минималках границы указателей задаются для объектов на стеке и при выделении в куче, но рядом часто хватает безграничных указателей (не возможно от них сразу отказаться при использовании уже написанного софта).
Поэтому там всегда очень много работы по реальному портированию. Причем отдельная головная боль с проталкиванием патчей в апстрим, а затем с адаптацией новых версий (т.е. повторное портирование).
Это сизифов труд, примерно такой-же что делают внутри МЦСТ и Базальте для поддержки e2k.Поэтому cherribsd всегда будет в состоянии "почти готово", и одновременно "непригодно", в зависимости от критериев. Собственно уже почти 5 лет в таком состоянии (и это не плохо, а хорошо, ибо процесс портирования/переписывания софта не стоит на месте).
---Что касается "Похоже никому это не надо".
Ну да, так оно и есть.
Побеждает подход "пусть нам сделают" (реинкарнация "мы все купим") и "мы будем интегрироваться в разработку" (сосать, делать дутые "прорывы" и получать технологическую зависимость).
Ну и фабрик нет, нет тиража, цена за штуку заоблачная.Будет как со станками.
Свои делать добровольно разучились в конце 80-х.
А теперь как-то их втаскивают, даже в обход санкций.Главное потом не ныть что "мы отстали" и "у нас ничего нет", а вспомнить что "Похоже никому это не надо".
> Поэтому для совместимости с унаследованным кодом эти границы могут просто устанавливаются на максимум, что почти отключает всю безопасность.в MTE этой границы вообще нет и оно уже в майнстриме в андроид работает - с явной границей надёжней но сравнение тэгов никуда не девается, но это проще конечно чем CHERI
> Свои делать добровольно разучились в конце 80-х.
интересно откуда этот миф что до 80-х было развитое станкостроение - в численном отношениии их дохрена было своих а вот в качественном.. как нам говорили (когда уже можно было) - всё что южней Воронежа делается это металлолом уже с завода.
> в MTE этой границы вообще нет и оно уже в майнстриме в андроид работает - с явной границей надёжней но сравнение тэгов никуда не девается, но это проще конечно чем CHERIMTE это скорее неплохая/удачная заплатка, в ответ на запрос гугла и яблочников "сделайте хоть что нибудь", вместе с угрозами заняться дизайном и выпуском собственных ЦПУ (что всё-таки и произошло).
ЧСХ, с интервалом в ~5 лет от нескольких "участников отечественного рынка" и экспертов минпромторга я слышал две оценки этой технологии/подхода:
- где-то в 14-15 годах "нам не подходит, ибо не даёт гарантий защиты";
- когда MTE появилось в силиконе "о как продумано и удобно, и переписывать ничего не нужно как для эльбрусов".Т.е. господа не хотят вникать, делать усилия и брать какую-либо ответственность, а просто греют стулья и пишут отписки.
> интересно откуда этот миф что до 80-х было развитое станкостроение - в численном отношениии их дохрена было своих а вот в качественном.. как нам говорили (когда уже можно было) - всё что южней Воронежа делается это металлолом уже с завода.
Оно было разное, очень сильно разное.
Были и прецизионные металлообрабатывающие станки, которые китайцы покупали по цене металлолома на одном из заводом имени Ленина, сильно южнее Воронежа.
Говорят работают до сих про, спустя >30 лет.
> Оно было разное, очень сильно разное.как и уровень жизни населения - была Москва с изобилием в магазинах для показухи и вся остальная страна с пустыми прилавками и колбасными электричками.
