Аарон Баллман (Aaron Ballman), главный сопровождающий компилятор Clang и участник команд разработки стандартов WG21 (C++) и WG14 (C), начал обсуждение добавления в компилятор Clang режима усиления безопасности. Новый режим позволит разом активировать набор опций для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened", при котором включаются опции "-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full"...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63675
А всё почему? А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить.
> А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить.Так а какие еще варианты, если язык дефективный by design. Это все-таки дешевле, чем переписывать миллионы легаси кода с C и C++ на Rust.
Дак и не надо всё переписывать. Надо только самое важное.
Ну вот один в истории так же подумал, а потом слонов через горы повёл.
и он не переписал самое важное, собственно поэтому проект провалился
Его ошибка в том, что он не реализовал победу при Каннах, а не в потерях при переправе.
Зависит от контекста. Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствия эксплуатации дыреней.Вообще переписывание чего бы то ни было (в том числе на тот же язык) является рефакторингом. Иногда это дешевле поддержки легаси. Иногда нет. Зависит от.
> Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствияЧто-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. В этих областях уж точно не сидели бы и не ждали до 202* года, пока им разработчики ГЦЦ/Шланг с барского плеча отсыпят костылей для затыкания дыр в недоязыках из 70-80.
Эти флажки как раз для 95% разработки, где на безопасность наплевать, причем настолько, что они в большинстве случаев даже эти опции компилятора не станут включать под предлогом того, что будут просадки производительности.
Для критичной безопасности выбор языка не имеет значения. К слову, для Си есть стандарты безопасного программирования.
В прочем, они тоже не имеют значения. Решает формальная верификация кода, а не эти игрища с "мой язык круче".
Подтверждаю. Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода. Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99 в зависимости от категории надежности ПО. На плюсах доказать что код работает так как положено очень тяжело. Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием(по требованиям низкого уровня), тестированием по требованиям высокого уровня, тестированием по требованиям комплексным и системным. Ну и пилоты испытатели в конце концов все тестируют на страх и риск. Ну и соответственно самые высокоуровневые тесты не всегда автоматизированы иногда они как протокол ручных манипуляций по приборной панели выполняются. А на уровне модульном и по аысокоуровневым требованиям конечно почти полная автоматизация со сбором покрытия и объяснением почему какое то покрытие не 100%. Пповеряетс как говорится любая операция в коде и последовательность выполнения тоже :). Это дорого и медленно, но вот в авиации лучше пока не придумали.Самолеты от этого не падают каждый раз кстати. Ну и конечно у нас embedded software а не ваши Intel Xeon с терабайтом ОЗУ. У нас ПЗУ то в десятках мегабайт измеряется на приборах часто а уж ОЗУ и подавно в десятках или сотнях КБ.
> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано.За примерами далеко не надо ходить:
sudo
Переписали конечно, потихоньку переходят. Но процесс не моментальный.
На счёт флагов компиляции. В 95% кроме оригинального разраба какойто проги/либы никто не знает, что имеет смысл тыкать. Ещё 5% приходится на прошареных пользователей и 0% на мейнтейнеров твоего диструбутива. Тем более, что если ты включил какую-то опцию, это не значит, что код стал быстрее. Это всё надо тестить.
Контрпример: doas.
command not found: doas
> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано.Да каеш. Критичное к безопасности, если что, это всё от дырявого насквозь openssl до дырявого насквозь ядра linux с rce во всяких уринах. Даже клоуны от безопасности openbsd принипиально пишут только на C.
Использования второго языка усложнит сопровождение не в два раз, а кратно!Если бы предлагалось переписать на безопасный, надёжный и верифицируемый язык типа SPARK (ADA), то аргументы можно было ещё принять. А переписывать на ржавый - только испортить простой код.
ещё можно dafny использовать и C код генерить.вообще есть масса возможностей, поэтому раст и не нужен
> ещё можно dafny использовать и C код генерить.
> вообще есть масса возможностей, поэтому раст и не нуженесли вы такие умные, то чего ̶т̶а̶к̶и̶е̶ ̶б̶е̶д̶н̶ы̶е̶ CVE/RCE до сих пор вы дыряшечном коде? (с)
Мне как-то в комментах на этом самом форуме СИшник рассказывал, что тесты не нужны, тк он и так знает что пишет, а ждать 10 минуть чтобы PR замерджить это слишком долго)
Если ты переписываешь с одного языка на другой, то у тебя остаётся один язык. Очевидно же.> язык типа SPARK (ADA)
На сколько сложно собрать команду из десятка программистов на Аде?
Очевидно что процесс переписывания занимает не один день. И месяцы-годы будет два языка как минимум.
Попробуйте найти хорошего специалиста который хорошо знает и C/C++, и Rust. И это пол беды. Если команда состояла преимущественно из сишников, процесс их перехода на раст будет тоже небыстрым. А бизнес простоев не любит. Поэтому будет несколько затянутых процессов одновременно:
- переписывание кода на раст;
- написание нового кода на раст;
- написание нового кода на си (да-да, мы в реальном мире, в котором идеальное не воплощается мгновенно, рук на раст сразу не хватит).
Ну, если это серьёзный проект, а не стартап на 1,5 строчки кода.
Эти процессы как раз в firefox можно наблюдать. За эти годы процент кода на rust – 12,3%.
После таких слов стало понятно что вы сударь теоретик. И принимать во внимание комментарии следует соответственно.
Похоже ни для чего кроме переписывания ХРуст не нужон
> Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию.Таких программ единицы. В Gentoo возможно для них прописать отдельные опции сборки в /etc/portage
Ставим безопасные опции сборки и пересобираем мир.
А rust не нужен.
> В Gentoo
> пересобираем мирГентушникам нет покоя. 😂 Собирай-перекомпиляй!
Когда правильно собрал перекомпилировать не надо.
А есть люди, которые ставят приложение в пару кликов. Представляете?
> А есть люди, которые ставят приложение в пару кликов. Представляете?Вы что хотите КАК В ВИНДЕ!?
Линукс создан для страданий и превозмоганий.
Если дать людям удобный способ хотя бы устанавливать ПО нормально, то они расслабятся, размякнут и что потом?
Попросят делать UI/UX хорошо, а не как "бомж вася, по совместительству дизигнер в СПО проекте наблевал на экран" ?
> Линукс создан для страданий и превозмоганий.Второй десяток лет пользуюсь, и вижу только как страдают виндузятники, то там не работает, то чтото не ставится...а мне надо файлек расшарить, 2 строки в нжинкс, надо снапшот системы сделать - 1 команда, еще одна и скопировал на другой диск...упал впн, 1 команда поднялся другой...блин вот 0 проблем, завернуть сайт почты россии так чтобы он ходил в обход впн, как нефиг, чядн?
Ты все делаешь так)
Просто ты не учитываешь годы, потраченные на изучение этих команд и прдолинг с консолькой.
Для нормального юзера файл шарится чегез гугл-драйв в тот же 1 клик.Но рассказы про УМВР - это классика красноглазых форумов.
Если у вас все работает, то чего появляются темы "Как избавиться от щелчков при запуске приложений на системах с чипами Intel" ?
А проблемы с дровами? А с софтом?
> А есть люди, которые ставят приложение в пару кликов. Представляете?Одно приложение? Даже и в пару кликов!!!
Эти, даже представить себе не могут, что гентушник, всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.
А Я ОДНИМ нажатием на Enter, могу создать всю систему с нуля, пересобрать мир правильно и создать с него LiveDVD.
И с этого LivDVD могу ОДНИМ нажатием на Enter установить готовую собранную систему.
Никому, кроме тебя, не нужную?
> Эти, даже представить себе не могут, что гентушник,
> всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.Да, нужно только исправить все сломанное в portage.
А потом можно пойти попить чай на полдня или даже на день, смотря на каком унитазе он решил попомпилять.
Ты используешь эти флаги? В частности, - D_FORTIFY_SOURCE=3 интересует. Я читал, он прям сильно роняет производительность
> Я читал, он прям сильно роняет производительностьНу, за безопасность нужно платить. Главное, что Раста нет.
Раст или так же роняет производительность либо имеет под собой худшую защиту.
> Раст или так же роняет производительность либо имеет под собой худшую защиту.Нет. В расте за лучшую защиты ты платишь размером временных файлов и временем компиляции во время которого проводятся все проверки - анализ лайфтаймов, владение, типизация и так далее.
Вот только программа компилится только один раз, а запускается на порядки больше раз (за исключением гентушников-ноулаферов, которым только дай покомпилять).
А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.
Но диды продолжаю ныть "раст не влазит на мой HDD 40GB", "лиса компилируется долго", "это нужно целую билдферму делать".
> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.Это небольшая цена за победу над Растом. Я лично готов и большее терпеть и превозмогать. Надо будет - и ядро буду сам пересобирать с отключенным Растом.
> Это небольшая цена за победу над Растом.Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.
> Я лично готов и большее терпеть и превозмогать.
Да без проблем. Терпите и превозмогайте.
> Надо будет - и ядро буду сам пересобирать с отключенным Растом.
Пока дрова на нем не будут писать))
Хотя можно страдать еще больше и сидеть без дров.
> Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.Я в сишке опции компилятора включу и буду сидеть в безопасности. А чтобы бороться с Растом мне вообще ничего не нужно делать (ну, кроме написания опеннетных комментариев).
> Пока дрова на нем не будут писать))
> Хотя можно страдать еще больше и сидеть без дровОй, напугали. Мне чтобы с консолью сношаться эти ваши растовые дрова и не нужны.
> "раст не влазит на мой HDD 40GB"И в чём они неправы?
> И в чём они неправы?В том, что для каждого времени и для каждого инструмента есть свои требования.
HDD 40GB должны остаться где-то... во временах Maxtor, если вы еще помните такую фирму))Новый инструмент дает новые гарантии, но и просит "оплатить" это требованиями к железу.
Если ваше железо не соответствует - это ваша проблема.Вы же не возмущаетесь что современное авто невозможно нормально отремонтировать в гараже?
Вот тут аналогичная ситуация.
А можно чуть раскрыть тему для нубов в расте?
Растоводы кричат что всё пучком.
> Растоводы кричат что всё пучкомВоут, мерзавцы! Все медленно, гарантий нет, бинари жирные, синтаксис вырвиглазный, неподдерживаемое, абыр, АБЫРВАЛГ111
> А можно чуть раскрыть тему для нубов в расте?
> Растоводы кричат что всё пучком.Ну, обычная методичка местных военов против раста.
Типа "жирные бинари", "жирный, обязательный рантайм" и прочего.У них даже получалось хелловорлды на расте собирать чуть ли не на десяток МБ, что конечно же служит самым веским доказательством их̵ ̵к̵р̵и̵в̵ы̵х̵ ̵р̵у̵к̵ их тезисов.
А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот меньше 1КБ и предложит поискать там рантайм и "жир", можно заявить, что это враки и несчитается и вообще, на си/асме можно еще меньше написать (правда, демонстрировать это военам некогда, им дальше супротив раста воевать надо).
> Растоводы кричат что всё пучком.Просто нет на них Дмитрия Пучкова.
Потому что си не умеет безопасно работать с памятью!
Как и ассемблер...
Ассемблер - это низкоуровневый язык, там это не так зашкварно.
А СИ - ассемблер, где наборы ассемблерных мнемоник просто заменены операторами с автоподстановкой подходящего регистра. Потому трансляторы С->АСМ такие простые и быстрые.
значит я могу смело в резюме писать что умею на ассемблере?
Если вы — транслятор.
> Потому что си не умеет безопасно работать с памятью!Потому что это просто кроссплатформенный ассемблер, который был создан для ускорение портирования юникса и прочего софта с PDP-11 на "более новые" машины.
А размер всего юникса того времени был около 100кLOC, что на порядки меньше размеров современных программ (ядро линя - 40MLOC)Но, из-за простоты сишки, отсутствия необходимости думать и того, что на ней писать начать может даже обезьяна, сишка стала ПХП своего времени и вытеснила другие нормальные языки.
Результаты чего мы наблюдаем даже через 50 лет.
> юникса и прочего софта с PDP-11 на "более новые" машины.
> А размер всего юникса того времени был около 100кLOC,100кLOC, это уже V7. Меньше:
PDP-7
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 36 11599 11378 0 221
V5
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 207 33538 31463 58 2017
C 122 27429 24006 1018 2405
C Header 13 418 357 34 27
V7
https://github.com/dspinellis/unix-history-repo/tree/Researc...
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 129 19982 18433 2 1547
C 862 157003 134476 8122 14405
C Header 109 6572 5111 838 623
BSD-1
https://github.com/dspinellis/unix-history-repo/tree/BSD-1
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 56 5799 5655 1 143
C 316 55378 43588 7694 4096
C Header 29 4018 2580 1089 349
это не молоток не может забивать гвозди и отбивает пальцы, а криворукий, держащий этот молоток :)
Ты не поверишь, но даже к молотку есть требования)
Что-то типа:
"Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой части и быть надежно насажены на рукоятки."Т.е если какой-то производитель выпустит молоток, который раз в год ̶с̶т̶р̶е̶л̶я̶е̶т̶ ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким куском кала пользоваться нельзя.
Более того, есть даже правила для ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶ ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶ защиты:
"При работах инструментами ударного действия работники должны пользоваться защитными очками для предотвращения попадания в глаза отлетающих твердых частиц."Так что иди учи уроки, а потом придумай более хорошую аналогию)
> Ты не поверишь, но даже к молотку есть требования)
> Что-то типа:
> "Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой
> части и быть надежно насажены на рукоятки."Ну и как эти требования отменяют факт попадания молотком по пальцу? Даже бумажным молотком мы попадем по пальцу при условии криворукости нашей, а не из-за того, что молоток бумажный, а не резиновый.
> Т.е если какой-то производитель выпустит молоток, который раз в год ̶с̶т̶р̶е̶л̶я̶е̶т̶
> ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким
> куском кала пользоваться нельзя.Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу. Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то.
> Более того, есть даже правила для ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶
> ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶
> защиты:
> "При работах инструментами ударного действия работники должны пользоваться защитными
> очками для предотвращения попадания в глаза отлетающих твердых частиц."В список этих требований еще должны входить всякие требования на гвозди по ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли?
> Так что иди учи уроки, а потом придумай более хорошую аналогию)
Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :)
> Ну и как эти требования отменяют факт попадания молотком по пальцу?А при чем тут палец?
Вы тут RCE с пальце не сравнивайте)СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу".
> Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу.
Последствия)
От резиновго будет шишка, а от железного можно и ноги протянуть.> Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то.
Если голова молотка закреплена плохо по ТУ производителя - то это просто овняный инструмент.
Примерно как СИшка с ее УБ.> В список этих требований еще должны входить всякие требования на гвозди по ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли?
Нет не должны.
Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью.
Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том числе прочность.И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло.
В куче отраслей всякие ТБ штуки являются обязательными и никто не будет рассказывать "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий", "от васи осталась горстка пепла не потому что он поленился взять изолирующий ковер, а потому что криворукость".
Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется.
> Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :)Ого, это что-то новое.
> А при чем тут палец?
> Вы тут RCE с пальце не сравнивайте)
> СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу".Ну это зависит от оценки ущерба (урона, болевой порог и т.д.), в моем посыле это не важно, что удар по пальцу, что по лбу - равносильный урон, больно в любом случае. Я даже не отрицаю случая, что вам даже не будет больно от удара по пальцу, когда вы лишены болевых чувств. Но это не отеняет факта криворукости, а оно определяется именно попаданием молотом по всему (палец, лоб, ногу и т.д.), но не по прямому назначению - гвоздю.
> Последствия)
> От резиновго будет шишка, а от железного можно и ноги протянуть.То есть, предлагаете забивать гвозди бумажным молотом? Мы же за криворукость говорим, ведь не последствия (боль) определяет криворукость, не "материал" молота, а именно те действия которые приводят к попаданию по пальцу (выше дано определение криворукости).
> Если голова молотка закреплена плохо по ТУ производителя - то это просто
> овняный инструмент.
> Примерно как СИшка с ее УБ.УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ?
> Нет не должны.
> Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью.Какой расходник? Это вам не масло (которое кстати тоже подчиняется всяким требованиям), которое надо заменять после отработки ресурса. И в случае сварки электроды - не расходник, а прямое назначение. Может вам производят бумажные гвозди, которые необходимо забивать железным молотом?
> Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том
> числе прочность.Ну ударьте с большей силой по гвоздю он разлетится на куски, это разве не криворукость людская, которая не контролирует силу удара?
> И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло.
Ток аргументы ваши так же звучат уныло.
Ударять молотом по пальцу - следствие КРИВОРУКОСТИ!
> "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий"
Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник.
> Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется.
Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит.
> Ого, это что-то новое.
Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить :) Могу ошибаться.
> УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ?Только после того как мне показжут язык без компилятора)
>> "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий"
> Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник.Отлично, а теперь усложним мысленный эксперимент.
Пусть на станке не было кожуха никогда.
Вот его производителю было плевать - ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶ петровичи - они ж расходники.
Является это инструмент хорошим?Ну или какая-то копейка где нет даже ремней безопасности. Является ли это автомобилем или ведром с гайками?
Двойная изоляция в электроинструменте появилась не просто так и стала стандартом.
> Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит.
У андроидщиков пока все получается.
Они даже писали что ошибок по памяти в раст коде за год (ЕМНИП) у них не было ни одной.> Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить
> :) Могу ошибаться.Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔
Но тоже могу ошибаться)
> Только после того как мне показжут язык без компилятора)А с чего вы сделали такой вывод? Компилятор следует стандарту языка, язык без компилятора существует, а вот компилятора без языка - нет :) Мне не нужен коредуб, чтобы исполнить какой-нибудь алгоритм, достаточно терминов машины Тьюринга.
Язык один, а компиляторов может быть много.
> Отлично, а теперь усложним мысленный эксперимент.
> Пусть на станке не было кожуха никогда.
> Вот его производителю было плевать - ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶
> петровичи - они ж расходники.
> Является это инструмент хорошим?Если в его инструкции по применению написано "пальцы и другие части тела в данную область не совать", то можно сказать - хороший инструмент. Вопрос в другом, должны ли быть описаны все случаи жизни в этой инструкции? К примеру, в инструкции к применению ядерной бомбы написано - "Не прикуривать" :) Думаю инструкции на все случаи жизни должны быть описаны в стандартах по производству этих инструментов, но а кто перечислил все эти случаи жизни? Говорить, что отныне все компиляторы языков должны автоматически управлять памятью, было бы отлично, но какова цена этого?
> Ну или какая-то копейка где нет даже ремней безопасности. Является ли это
> автомобилем или ведром с гайками?Это автомобиль по задумке, и по стандартам - отрицать это бред. А по каким стандартам это уже разговор из другой серии.
> Двойная изоляция в электроинструменте появилась не просто так и стала стандартом.
Почему до сих пор электричество убивает? Почему не придумать стандарт электричества, которое не убивает? Мы должны придумывать стандарты розеток куда нет физ. возможности сунуть пальцы? Или от короткого замыкания перестало происходить возгорание и как следствие - пожары.
> У андроидщиков пока все получается.
> Они даже писали что ошибок по памяти в раст коде за год
> (ЕМНИП) у них не было ни одной.также говорят и пхпешники, которые понятие не имеют, что такое память.
> Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔
> Но тоже могу ошибаться)а возможно, я совсем забыл, что нахожусь в среде где "товарищмайор,разрешитедоложить" это ген :)
Молоток виноват в том, что не распознаёт объект, по которому бьёт и мгновенно не меняет материал бойка: от комка ваты, если там палец, до нейтринного уберкомпактного освинцованного слитка, если это гвоздь.Именно поэтому я смотрю уже три года на все эти споры си-раст-<баззвордязык>, как на битву слабоумных, рассуждающих, что тёплое лучше мягкого потому, что оно зелёное, но в крапинку и кузявее сладкого, но в форме перца с запахом апельсина.
Покажи пряморуких сишников, которые не ошибаются в работе с памятью. Очень интересно.
> Покажи пряморуких сишников, которые не ошибаются в работе с памятью.Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю!
> Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю!И много у тебя их осталось?))
> И много у тебя их осталось?))А много их у тех, кто "грызет гранит науки"? Вот когда вы попробуете "погрызть гранит Си", у вас будет ровно столько "зубов".
У нас как у орков в вахе они сами растут) Поэтому и топим за С
> Покажи пряморуких сишниковну как показать вам код, который под NDA? Хотя тут надо отвечать вопросом на вопрос, к примеру - "покажи мне код работы с памятью где каждый сишник допустит ошибку (своего рода палающий баг)", но в таком случае баг даже не в работе с памятью, а в архитектуре алгоритма, которая допускает эту "плавучесть", но даже если это одно единственное исключение (исключительная ситуация), всегда можно его отдельно обработать.
Так что, при прямых руках и камнем можно забить гвоздь и микроскопом, не отбив пальца.
> "покажи мне код работы с памятью где каждый сишник допустит ошибку"Так проблема в том, что каждый сишник ошибается немного в другом месте.
А результат один и тот же.> ну как показать вам код, который под NDA?
Мы регулярно наблюдаем дыры и взломы проприетарных продуктов с использование buffer overflow, int overflow, double free и так далее.
Достаточно пройтись по тегу pwn2own (opennet.ru/keywords/pwn2own.html) и там будет просто море примеров.Из последнего (opennet.ru/opennews/art.shtml?num=63254)
VMware ESXi: 2 успешные атаки, позволившие выполнить код на стороне хост-окружения. Проблемы вызваны целочисленным переполнением и использованием неинициализированных переменных.VMware Workstation: Одна успешная атака, позволившая выполнить код на стороне хост-окружения. Проблема вызвана переполнением буфера.
Windows 11: 5 успешных атак, позволивших выполнить код с правами SYSTEM. Уязвимости вызваны обращением к памяти после освобождения, целочисленным переполнением, переполнением буфера, неправильной обработкой типов (Type Confusion) и состоянием гонки.
А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам.
Типичные проблемы си и плюсов, несущих родовую травму сишки.
> Так проблема в том, что каждый сишник ошибается немного в другом месте.
> А результат один и тот же.Результат некорректного алгоритма - очевиден, и ошибка с памятью это формально некорректный алгоритм. В формально корректном алгоритме по определению нет ошибки, тем более с памятью.
> Мы регулярно наблюдаем дыры и взломы проприетарных продуктов с использование buffer overflow,
> int overflow, double free и так далее.Ну это говорит только о криворукости не более, кто-нибудь приведет мне пример алгоритма, который всегда будет содержать "int overflow, double free и так далее"? Нет? так в чем дело в Си? На Си нельзя писать формально корректные алгоритмы?
> А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам.
> Типичные проблемы си и плюсов, несущих родовую травму сишки.Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь? Мы пытаемся их приспособить - протезирование и т.д. Но тем не менее даже в таком случае мы разве должны требовать от них умение жонглирования? Думаю, нет, не логично ибо они ограниченны.
Отсюда, если вы всякий раз Сишкой стреляете себе в ногу, то вам не Сишку менять надо на раст, а стоит задуматься над тем, стоит ли заниматься тем где вы ограниченны.
> ошибка с памятью это формально некорректный алгоритмТочно? Или может это проблема в конкретной реализации конкретного алгоритма?
> Ну это говорит только о криворукости не более,
Проблема в то, что пряморуких сишников не существует.
Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки.> На Си нельзя писать формально корректные алгоритмы?
На си нельзя два числа сложить чтобы не получить UB))
> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов
А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то оно может показаться оскорбительным.
> Отсюда, если вы всякий раз Сишкой стреляете себе в ногу,
Я себе в ногу не стреляю - я на этом слава богу вообще не пишу.
Зато наблюдаю, как с завидной регулярность стреляют другие.
И иногда мне отстреливает ногу просто рикошетом.Кстати, раз вы начали про стрельбу - как вы думаете, почему требование наличия предохранителя стало законодательным, а не "по желанию производителя", а в тот же глок добавили аж три предохранителя - trigger safety, firing pin safety и drop safety?
Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы.Вот у тут будет так же - 6ыdlокодеры на недоязычке так и не научатся писать без багов с памятью за 40+ лет и из законодательно заставят на нем перестать писать.
ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь не быстрая.
>> ошибка с памятью это формально некорректный алгоритм
> Точно? Или может это проблема в конкретной реализации конкретного алгоритма?А вы как формально описали память? Выход за границу у вас также формально должен быть описан, и случаи его обработки и т.д. И в итоге у вас и будет формально корректный алгоритм. А реализация - дело техники, хоть на машине Тьюринга, хоть на коредуба, неважно.
> Проблема в то, что пряморуких сишников не существует.
> Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки.Ну как и тех, кто в руках держал молот и ни разу по пальцу не попал. Но это не отменяет того факта, что молотом можно бить по гвоздю и не попадать по пальцу, для этого достаточно быть ПРЯМОРУКИМ!
> На си нельзя два числа сложить чтобы не получить UB))
Это к компилятору, а не к языку.
> А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то
> оно может показаться оскорбительным.С коих пор инвалид это оскорбление? Человек ограничен в чем-то и для какой-то работы он по факту инвалид, тут ничего оскорбительного нет. Зачем "заставлять" (байтить) безрукого или с протезами жонглировать? Хочет - пусть жонглирует, но требовать от него это делать как делают профи - маразм! Я не запрещаю криворуким писать на Си, пишите ради Бога. В этом то и суть отличия профи от инвалида (ограниченного в возможностях, способностях), и там где необходимо работа профи - должен работать профи, от этого инвалид оскорбляться не должен, а должен понимать свои ограничения и держаться подальше.
> Я себе в ногу не стреляю - я на этом слава богу
> вообще не пишу.
> Зато наблюдаю, как с завидной регулярность стреляют другие.
> И иногда мне отстреливает ногу просто рикошетом.Если вы не профи в грибах и пытаетесь съесть каждый найденный в лесу гриб, то какова вероятность вашего отравления? Такая же аналогия с саперным делом, одна ошибка ценой в жизнь. Какой результат будет от не профи в этой области?
> Кстати, раз вы начали про стрельбу - как вы думаете, почему требование
> наличия предохранителя стало законодательным, а не "по желанию производителя", а в
> тот же глок добавили аж три предохранителя - trigger safety, firing
> pin safety и drop safety?
> Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы.Стоп, дефективность изделия - отдельная тема контроля качества (дефектный молот (из сталь другой марки) не обязан всегда по пальцу ударять). В вашем примере предохранитель нужен от случайного выстрела, который по большей части происходил когда тупо оружие роняли из рук на пол. Ну это разве не криворукость на лицо? Ровно поэтому там и скоба есть, прикрывающая спусковой крючок:)
> Вот у тут будет так же - 6ыdlокодеры на недоязычке так и
> не научатся писать без багов с памятью за 40+ лет и
> из законодательно заставят на нем перестать писать.
> ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь
> не быстрая.Людское законодательство - маразм, они вам завтра запретят вообще что-либо писать. Ну как при Екатерине:
"""
О бытiи помѣщичьимъ людямъ и крестьянамъ въ повиновенiи и послушанiи у своихъ помѣщиковъ, и о неподаванiи челобитенъ въ собственныя Ея Величества руки.
"""//ru.wikipedia.org/wiki/Крепостное_право_в_России
> для этого достаточно быть ПРЯМОРУКИМ!Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет и все))
> Это к компилятору, а не к языку.
Нет, именно к языку. Который в недостандарте под названием ISO/IEC 9899 объявил, что signed integer overflow это undefined behavior.
Не unspecified behavior, не implementation-defined behavior, а именно undefined, с которым программа теряет Conformance и компилятор может преобразовать этот код во что угодно.ISO/IEC 9899, пункт 3.4.3
EXAMPLE An example of undefined behavior is the behavior on integer overflowИ это только одно из 193 UB в С99 (gist.github.com/Earnestly/7c903f481ff9d29a3dd1)
Стандарт сишки - овно, просто defective by design. Очевидно почему так произошло, если посмотреть на даты стандартизации и создания сишки, но это не оправдание.Не знаю почему на него так яростно наяривают апологеты сишки, наверное просто больше не на что. Сам создатель сишки Денис Ритчи писал про "стандартизацию":
-- The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use. --> Стоп, дефективность изделия - отдельная тема контроля качества
Нет, сишки дефектна начиная со стандарта. Она до сих пор застряла в 70х.
Ее уже не исправишь, лучше сразу закопать.> Людское законодательство - маразм
Беззаконие или закон божий лучше?))
> Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет
> и все))Если сишник всю жизнь писал хелловроты он пряморукий?
> Нет, именно к языку. Который в недостандарте под названием ISO/IEC 9899 объявил,
> что signed integer overflow это undefined behavior.
> программа теряет Conformance и компилятор может преобразовать этот код во что
> угодно.Так в чем проблема, в вашем компиляторе? Он не дал вам никаких средств обработки этих ситуаций? Язык то причем? Или там где происходит "signed integer overflow" это непредсказуемая и не решаемая проблема, как проблема останова? Язык говорит - решай как знаешь, в чем проблема? Вы хотели, чтобы там написано было - "делай так и никак иначе"?
> Не знаю почему на него так яростно наяривают апологеты сишки, наверное просто
> больше не на что. Сам создатель сишки Денис Ритчи писал про
> "стандартизацию":
> -- The fundamental problem is that it is not possible to write
> real programs using the X3J11 definition of C. The committee has
> created an unreal language that no one can or will actually
> use. --Ну так все ваши претензии это претензии к компилятору. Стандарт не требует ничего невозможного, на что можно было бы сослаться и сказать - это что за язык такой, "язык сломаешь пока выговоришь", тип такого.
> Нет, сишки дефектна начиная со стандарта. Она до сих пор застряла в
> 70х.
> Ее уже не исправишь, лучше сразу закопать.Ну вот давайте конкретно исправим "signed integer overflow", что мы должны записать в стандарте?
>> Людское законодательство - маразм
> Беззаконие или закон божий лучше?))А кто-то уже законы природы отменил? Беззакония по определению нет, если принять за аксиому детерминизм всего бытия.
> Если сишник всю жизнь писал хелловроты он пряморукий?Нет, он просто еще не показал свою криворукость))
> Язык то причем?
При том, что это в "стандарте" языка есть UB, а не в компиляторе.
> Язык говорит - решай как знаешь
Неа, "решай как знаешь" это implementation defined, а не UB.
А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так."Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить. То что всякие gcc/clang налепили костылей чтобы результаты жизнедеятельности погромистов можно было хоть как-то скомпилить... ну так это как раз workaround дефективного стандарта.
> Стандарт не требует ничего невозможного
"Стандарт" не выполняет свою функцию - однозначного определения поведения.
> Ну вот давайте конкретно исправим "signed integer overflow",
> что мы должны записать в стандарте?Записать однозначное поведение в виде "two's complement wrapping".
А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах!Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте.
> А кто-то уже законы природы отменил?
"Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее.
> При том, что это в "стандарте" языка есть UB, а не в компиляторе.И что? написано ведь "решай как знаешь".
> Неа, "решай как знаешь" это implementation defined, а не UB.
> А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так.""решай как знаешь" это и есть ""x** его знает как оно должно быть", поэтому ответственность переложили на компилятор, "решай и делай сам, как хочешь". Если бы писаки стандарта пришли бы к какому-то мнению как это разрешить, то они предложили бы и это было бы вовсе не UB как вы заметили. А почему они не предложили, на то есть конкретные причины, надо спросить у писак стандарта.
А "implementation defined" - это "делай как хочешь".
> Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить.
UB часть стандарта, и разрешения этой ситуации стандарт переложил на плечи компилятора.
> "Стандарт" не выполняет свою функцию - однозначного определения поведения.
Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту.
> Записать однозначное поведение в виде "two's complement wrapping".
> А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах!Стандарт не обязан это описывать если это тупо решается средствами языка.
> Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте.
На все есть причины, в стандарте если не описаны какие-либо проверки на выходы за границы, это не означает, что их невозможно предотвратить средствами самого языка.
> "Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее.
кто-то ему может это запретить сделать? А его сосед придет и поступит с ним также, в чем проблема? Природа существует в балансе, нет такого "паразита", который может уничтожить всю природу и т.д. И ни одно существо не способно нарушить этот баланс, то есть законы природы.
> Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту.Ахаха! Бл.... Прям в "Фонд золотых цитат сишников"!
А нафига нужен такой стандарт, который "формальность"?
У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?))> в стандарте если не описаны какие-либо проверки на выходы за границы,
> это не означает, что их невозможно предотвратить средствами самого языка.Кажется ты не понимаешь.
Когда компилятор "видит" UB, то для него это "невозможный" код.
Он может его просто выбросить и заменить на no-op.Вот у АДА Спарк нормальный стандарт. Там не только нет UB, но и для того, чтобы называть себя "компилятор языка Ада" нужно пройти проверку на тестовых данных.
А для сишки любой кал может назваться "компилятором си".
Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку.
> У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?))если потребитель это схавает, то допустимо. Иначе он (потребитель) должен проверить на соответствие этим стандартам, стандарты без проверки - "вилами по воде".
> Когда компилятор "видит" UB, то для него это "невозможный" код.
Отлично, остановись моя программа, в чем проблема?
> Он может его просто выбросить и заменить на no-op.
Да ради Бога, замени хоть на хеловрот, в чем проблема? Стандарт вам говорит "решай как хочешь", компилятор "решает" как хочет, так в чем проблема? Проблема в том, что это не совсем то, что вы "хотите"? Так кого это должно волновать то?
> А для сишки любой кал может назваться "компилятором си".
если реализует язык по описанному стандарту, в чем проблема?
> Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку.
"Преступление и наказание" шедевр не от того, что написана на русском языке!
> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь?Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые получают над ними конкурентное преимущество. И с вашей Сишочкой происходит буквально то же самое: еще в начале нулевых она вымерла во всех областях, кроме древнего легаси и embedded, а теперь и в них она окончательно добивается Растом.
> Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые
> получают над ними конкурентное преимущество.Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации больше. И выживает не сильнейший и могучий, а желающий жить. Люди без ног на двух протезах Эвересты покоряют, но не факт, что Эверест покорит самый здоровый человек. И таких примеров много.
> еще в начале нулевых она вымерла во всехВыходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет. Может у вас другое определение процесса вымирания?
> Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации большеА у девчуль больше мотивации заводить пары с двурукими, чем с безрукими. В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни.
Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг.
> Выходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет
Ну так я назвал ровно две обоасти, в которых Си пока еще не умер: легаси и встройка (как правило два в одном). Знаете еще хоть одну область, где Си еще жив как основной язык?
> А у девчуль больше мотивации заводить пары с двурукими, чем с безрукими.А безруких девчуль природа уже отменила? Это что-то из серии про "девочки не пукают"?
> В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни.
Продолжение рода это есть цель такая?
> Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг.
Подмена понятий, "безрукий" - человек, а не язык.
> Знаете еще хоть одну область, где Си еще жив как основной язык?
я не знаю, что такое "легаси", дайте определение.
>> Покажи пряморуких сишников
> ну как показать вам код, который под NDA?Он не просил показать код - он просил показать показать пряморуких сишников. А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂
> Он не просил показать код - он просил показать показать пряморуких сишников.
> А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂я вайбкодер, я квадробер :)
Я не могу проверить, действительно ли сишный код под NDA так хорош, так что для меня это из разряда веры, я знаю только, что из открытых проектов на сишке примерно все имеют в анамнезе ошибки работы с памятью.
> Я не могу проверить, действительно ли сишный код под NDA так хорошну а мне как проверить, действительно ли "прямые" руки у программиста?
Твоё мнение насчёт прямоты рук не имеет практического смысла, факт в том, что примерно все сишки не могут писать код без ошибок типа use-after-free, так что если на уровне языка можно избавиться от таких ошибок - это очень здорово.
> что примерно все сишки не могут писать код без ошибок типа use-after-free, так, что если на уровне языка можно избавиться от таких ошибок - это очень здорово.Ну избавились мы от этого и получили что? Раст? Какое средство языка си мешает избавлению от use-after-free? Тупо незнания со стороны программиста устройство памяти и ее контроля, и все! Все кто топит за то, чтобы это все делал за них компилятор - просто не знают как это решать, я другого объяснения не вижу.
> это очень здорово
было бы здорово, когда мне не будет необходимости вообще писать программы, пусть этим неблагодарным делом занимается другая программа, написанная один раз более "умелым" программистом.
Эх, сколько телодвижений для исправления того, что ущербно с даты создания.
Зато потом читаем клевую TEH DRAMA комитета по внедрению SafeC++.А ведь достаточно взять простой ржавый...
достаточно взять ржавый и начать писать extern "C" потому что без сишного ABI он никому не нужен
> достаточно взять ржавый и начать писать extern "C"
> потому что без сишного ABI он никому не нуженПлюсы без extern "C" тоже мало кому нужны.
Но это как раз стиму выбросить сишку отовсюду откуда возможно.
И все писать на расте))
Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go.
> Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go.https://doc.rust-lang.org/reference/items/external-blocks.html
The following ABI strings are supported on all platforms:
unsafe extern "Rust" – The default ABI when you write a normal fn foo() in any Rust code.
unsafe extern "C" – This is the same as extern fn foo(); whatever the default your C compiler supports.
unsafe extern "system" – Usually the same as extern "C", except on Win32, in which case it’s "stdcall", or what you should use to link to the Windows API itself
There are also some platform-specific ABI strings:
unsafe extern "cdecl" – The default for x86_32 C code.
unsafe extern "stdcall" – The default for the Win32 API on x86_32.
unsafe extern "win64" – The default for C code on x86_64 Windows.
unsafe extern "sysv64" – The default for C code on non-Windows x86_64.
unsafe extern "aapcs" – The default for ARM.
unsafe extern "fastcall" – The fastcall ABI – corresponds to MSVC’s __fastcall and GCC and clang’s __attribute__((fastcall))
> Это просто невозможно, у Rust нет собственного ABIТы не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте.
> Ты не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте.Ты просто бьешь ниже пояса!
Или ты надеялся, что хотя бы половина местных 🤡 хотя бы открывала текст стандарта?
Зря мой друг, очень зря)
... и просто выбросить.
Режим, при котором для компиляции программы нужно будет проходить KYC (шутка).
Си - сила! Лучший язык программирования. И не стоит на месте, а развивается, не ломая совместимость при этом. А все нападки на Си - спланированная и оплаченная кампания по дескридитации с целью вытеснить независимых разработчиков из мира свободного ПО.
Рептилоиды придумали раст, чтобы подсадить на него человечество извести сишников, и больше никогда человечество не смогло вернуться к гнутым истокам как завещали наши великие предки.> спланированная и оплаченная
Зачем дурачкам платить, дурачки за просто так будут в лепешку расшибаться чтобы доказать чтото.
> чтобы подсадить на него человечество извести сишниковДа, подсадная утка, 100%!
> И не стоит на месте, а развивается, не ломая совместимость при этом.Аж жЫр с монитора потек.
> кампания по дескридитации
Никто не дискредитирует сишников так хорошо как сами сишники.
> оплаченная
Не правда! Я абсолютно без-воз-мезд-но, то есть даром (с) и с огромным удовольствием пишу про сишные дырени везде где можно. Ведь многие люди не знают про опасность, которую таит в себе 6ыdloкод не небезопасном йазычке из 70х! А потом они удивляются как их телегу ломают просто прислав "специально оформленное изображение".
Люди просто должны об этом знать, думать об этом, писать своему депутату "а вдруг в этом авто используется опасный код?!" и требовать запрета небезопасных языков.
И по последним изменениям видно, что эта деятельность дает свои плоды.
> Никто не дискредитирует сишников так хорошо как сами сишникиВесь лучший базовый софт, за счёт которого ещё не рушится, не смотря на все старания некоторых, а прочно стоит огромное здание современного IT, написан на Си.
> Весь лучший базовый софтА давай посчитаем, какой софт написан на сишечке, а какой на c++. С чего начнем?
С компиляторов? Оба два оптимизирующих на с++.
С ос? Видна это с++ и даже раст, макось - обжси.
С офисных пакетов? Там нет сишечки.
Может игрульки? На сишке нет ни одного современного движка.Так что написано на си, кроме ядра линя и то, только потому что фин не признает своих ошибок?
> прочно стоит огромное здание современного IT, написан на Си.
"Прочно" стоит на шатком фундаменте дырявейших поделий вроде libxml2)))
> С чего начнем?Да хотя бы Apache и nginx - несущие платформы всего сегодняшнего интернета! И с этим они более чем отлично справляются, и Си никак не мешает, если голова на плечах есть.
Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код? Хочу научиться программировать и разрываюсь между С/С++ и Rust. Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.
Ни на каком языке невозможно писать безопасный код - это архитектурный изъян человеческого мозга. Можно встроить в язык кучу костылей, которые снизят риск ошибок при работе с памятью, но это никак не поможет от совершения логических ошибок, которые приводят к уязвимостям.
В случае с С/С++ это человеческий фактор, так как компилятор ни о чём не предупреждает.
А в Rust компилятор все спорные ситуации покажет и откажется такой код компилировать.Я, как ленивая жопа, предпочитаю писать на Расте, так как это требует меньше когнитивных напряжений.
То есть, технически возможно писать безопасный код на С/С++? Все верно?
> То есть, технически возможно писать безопасный код на С/С++? Все верно?Технически, можно переделать стиральную машину или холодильник в космический корабль или подводную лодку, все верно.
Бензопила это безопасный инструмент?Допустим что да, тогда отбиться ей от нашествия зомби нельзя, а значит она не нужна
Допустим что нет, и маньяк может запилить десяток человек забежав на детский утренник, а значит она не нужна.
Пользуйтесь пилкой для ногтей
От зомби не поможет никак, но можно засадить комуто в глаз..но так их сейчас из пенопласта делают, абсолютно безопасная, но можно ее порезать и устроить так чтобы ктото задохнулся..но задушить можно и руками, черт. абсолютно безопасно только то чего не существует, но идеи убивают похлеще всяких оружий...то есть технически..ну вы поняли
То что возможно сломать будет сломано
> С/С++Нет такого языка. Есть Си, а есть С++ (на котором можно писать как на си, но не надо так!)
Внимательность человека это тоже ресурс и он конечен.
У кого-то больше, у кого-то меньше, но всегда наступает момент когда человек допускает ошибку. Поэтому намного лучше выбирать язык, где тупые и рутинные действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное - логику программы.Современный с++ неплох, начиная наверное с с++17. Но наследственные дефекты си в нем остались. Писать нормально на нем можно, но довольно сложно и "дорого".
Можно почитать какой ценой досталась надежность напр. llvm, сколько человекочасов они потратили на тесты, фаззинг, санитайзеры и так далее.
Прямо указал что языки, а не язык.
> Поэтому намного лучше выбирать язык, где тупые и рутинные
> действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное
> - логику программы.с каких пор программирование это рутина? вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и боитесь в какой-то момент по невнимательности допустить всякого рода целочисленных переполнений? От такой рутины должен спасть вас язык, компилятор и т.д.? Я вот думаю вы вовсе не программированием занимаетесь, а как сами описали - рутиной.
> с каких пор программирование это рутина?А где там написано что "программирование это рутина"?
Там написано про рутинные действия в рамках программирования. Это огромная разница.
В любой работе есть рутинные элементы, а есть творческие.Даже в художке - подготовка холста, мойка кисточек и тд - это рутина. И кстати именно поэтому многие просто покупают готовых холст в магазе или автомойку для кисточек - они не хотят тратить свое время на ерунду, а хотят творить.
Вот раньше диды в vi писали код, и имя каждой переменной/функции полностью вписывали.
А сейчас эту рутину делает IDE в виде автодополнения.> вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и
> боитесь в какой-то момент по невнимательности допустить всякого рода
> целочисленных переполненийНе боюсь потому что в нормальных языках там нет проблемы.
А в "особенных" нужно задумываться "а что будет если будет переполнение?", "а как именно оно будет реализовано?", а "что если компилятор будет другой? или версия обновится?"
> А сейчас эту рутину делает IDE в виде автодополненияЯ вспомнил об этом 10 лет назад, когда в одной отечественной cms неправильно писал название функции getTreeStucture и не понимал, почему оно её не находит. Оказалось, потому что я писал её без автодополнения и без ошибки как getTreeStructure, а разработчики этой cms один раз написали неправильно а потом только автодополняли. Лучший способ не допустить ошибку - это скрыть ошибку.
А в чем ошибка-то?
Опечатка в имени функции никак не влияет на то, во что эта функция скомпилится.
Оно никак не влияет на работу программы.
Отлично.> чтобы расходовать свою внимательность на что-то более важное - логику программы.
Ок, допустим внимательности Х - const, и за 3 дня человек допускает Y ошибок, тогда логичнее их допустить в рутинных вещах, изза которых программа либо не собирется, либо не запустится, что укажет на ошибку, чем через 10 лет обнаружить, что логика кривая.
> тогда логичнее их допустить в рутинных вещах, из-за которых
> программа либо не собирется, либо не запустится,Именно. Вот только это про раст, а не про си.
Ты накосячил - компилятор просто не скомпилит это.
А сишку он скомпилит, запустит, а потом через Т лет окажется что 28 backspace позволяют обойти ввод пароля.> чем через 10 лет обнаружить, что логика кривая.
Да, именно так! Поэтому лучше тратить внимательность на логику, а не на ерунду.
> лучше тратить внимательность на логику, а не на ерунду.Я без предъяв, но вы не рассматриваете вариант, что тратя внимательность на ерунду я эту самую внимательность развиваю?
> тратя внимательность на ерунду я эту самую внимательность развиваю?Возможно. Но ты ее точно также развиваешь, тратя не на ерунду.
И этой неерунды ты сможешь сделать намного больше до первой ошибки.
Плюс там есть гарантии, что за тебя проверят и сообщат "если что".
> Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код?На такой вопрос тебе никто не сможет ответь на 100%.
Всегда найдется умник с "зачем вы пишете с багами? пишите без багов!".
Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься)> Хочу научиться программировать и разрываюсь между С/С++ и Rust.
Если у тебя нет образования, я бы начал с алгоритмов и структур данных.
Потому что если у тебя будет фундамент - то в общем-то не так сложно переходить с одного языка на другой.Плюсы еще может имеют смысл - на них пишется много геймдева, пользовательского и научного софта.
СИшка уже безбожно устарела, только легаси и проектры от неосиляторов.Там нет кучи удобных вещей типа Result<value, error> (в С++ появилось в 23 стандарте - expected).
Приходится пробрасывать инты и потом "если -1 то ошибка". А если -2 - то она возможно и не обработается)
Не выглядит ли это просто убого?
Да и приводит к багам, как например тут
opennet.ru/openforum/vsluhforumID3/137136.html#82> Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.
Проблема в масштабе.
Следить за памятью в проекте из 10к строк легко. А если их будет 100к? Или миллион?
Приходится обмазываться санитайзерами, фаззингом.Так что лучше выбирай СИшку.
У меня, раст разработчика, будет меньше конкурентов ;)
> Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься)У любого языка, который много лет используется для написания тонн кода, вскроются "перманентные проблемы на десятки лет") "Ошибок нет только у того, кто ничего не делает".
> У любого языка, который много лет используется для написания тонн кода, вскроются "перманентные проблемы на десятки лет")И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа?
Или может у АДА есть проблемы уровня "28 раз нажал бекспейс - пропустил введение пароля"?Ненадо оправдывать бракованные недоязычки.
> "Ошибок нет только у того, кто ничего не делает".
А что делает тот, кто совершает одни и те же ошибки из года в год?
Знаешь, что такое безумие? (с)
> И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа?Всё есть, логические ошибки есть везде.
> А что делает тот, кто совершает одни и те же ошибки из года в год?В том, что ошибки обнаруживаются, нет ничего плохого - значит, тесты работают! Плохо, когда ошибок "как-будто нет" (их просто замаскировал "умный" компилятор), а потом эти скрытые логически ошибки, не обнаруживаемые тестами, приводят к катастрофическим последствиям...
> А что делает тот, кто совершает одни и те же ошибки из года в год?Имеете ввиду тот, кто из года в год придумывает всё новые "безопасные" языки, которые уж на этот-то раз точно избавят программиста от ошибок?
Ну, раз вы спросили, лично я думаю, что они это не для каких-то целей делают а просто потому что им захотелось создать новый язык с какой-нибудь фишкой. У кого-то это байткод и своя виртуальная машина размером с реальную, у кого-то отступы пробелами, у кого-то интерпретатор угадывающий нужна ли здесь точка с запятой или нет, у кого-то прикольный синтаксис, у кого-то компилируемость и при этом бинарник HelloWorld в несколько мегабайт.
> А что делает тот, кто совершает одни и те же ошибки из года в год?
> Знаешь, что такое безумие? (с)Криворукость сишников никто не отменял, но из этого не может следовать, что на си нельзя писать корректные "прямые" программы. По безумцам в обществе нельзя судить о пандемии, она должна носить тотальный характер.
Много работал с C/C++ в начале-середине 2000-х, но в некоммерческом применении. Сейчас эпизодически сталкиваюсь с ним. Про rust знаю только из новостей и (многочисленных) комментариев к ним. Всё ниже перечисленное (особенно касающееся rust) - исключительно мое субьективное мнение.На C/C++ можно писать безопасный код. Но для этого нужно:
- огромнейшая квалификация (например, необходимо знать ВСЕ undefined behavior), по ощущению, из 1000 C-программистов такая есть в лучшем случае у двоих,
- просто нереально огромное внимание к деталям: там, где вы описываете алгоритм и думаете над его реализацией, вам попутно необходимо думать и о куче мелочей типа "можно ли для сложения двух целых переменных просто написать a+b, или их сумма может превысить размерность переменной, и это необходимо сначала проверить и каким-то образом сгенерировать ошибку"; кроме совсем критичных областей, работодатель не даст столько времени на программирование.Как результат, на практике практически никто никаких проверок не делает.
Исторически С был высокоуровневым ассемблером и по сути использовался для более читабельной записи ассемблерного кода. Многие пишущие на C примерно понимали, как будет выглядеть ассемблерный код. Именно поэтому там нет строковых операторов, а только функции типа str* - процессор не умеет работать со строками. Именно поэтому там появилось многократное присваивание типа "a = b = c = d;" - один раз взять одно значение и записать в несколько переменных эффективнее, чем читать это значение из памяти каждый раз. Именно поэтому там куча undefined behavior: программист писал "a + b" и понимал, что это будет "add a, b", а переполнения будут обрабатываться в зависимости от процессора: на интелах просто отсечение старших битов и установка регистра флагов, на каких-нибудь моторолах - исключение и падение программы (написал просто для понимания, как именно переполнение обрабатывалось моторолами не знаю).
Это одна из причин, когда лет 15 назад (или больше?) была история, как Линус Торвальдс реализовал на голом C какую-то сумму типа sha256 и его код работал быстрее, чем код из openssl с поддержкой всяких sse и avx, - Линус просто понимал, какой конкретно бинарный код будет скомпилирован из его исходника.
Но последнее время (ну, лет 15-20) идёт сильный сдвиг C/C++ (особенно C++) в нишу "прикладных" языков, которые не зависят от железа. С добавлением соответствующих характеристик. Если в 80-е программист писал "add a, b" и точно знал, как результат поведёт себя на его конкретной машине, то сейчас авторы gcc явно используют undefined behavior для микрооптимизаций (на что тот же Линус Торвальдс много ругался несколько лет назад), и ваше a+b может уронить программу не потому что ваш процессор так работает, а потому что gcc знает что КАКОЙ-ТО процессор может уронить программу и поэтому даже для вашего процессора генерирует немного более оптимизированный код, но который может падать если сумма не входит в размерную сетку.
Rust же изначально был "оторван" от ассемблера и просто предлагает низкоуровневые абстракции, но без привязок к конкретному процессору.
Кроме того:
- rust защищает ТОЛЬКО от ошибок работы с памятью; всякие sql-инъекции, логические ошибки и всякое другое он не способен проверить; есть мнение, что rust, защищая от ошибок памяти, расслабляет программиста и отучает его думать и о других ошибках.
- Что касается синтаксиса, то C однозначно проще, чем rust, но вот последние версии C++ успешно борются с rust за звание наиболее ущербного.
- C/C++ имеют стабильные "релизы" языка; раст же постоянно меняется; вполне допускаю, что при нынешних скоростях развития лет через 10 раст будет объявлен устаревшим и на смену ему придёт что-то новое, а C/C++ для "небезопасных" программ будет ещё актуален; хотите постоянно бежать за всё обновляющимся растом или предпочтёте изучить что-то, что ещё долго будет актуальным? С другой стороны, сейчас раст слишком сильно форсируется крупными компаниями, этакий systemd. Есть шанс, что через 10 лет новые проекты на C/C++ начинаться вообще не будут.По ощущениям, раст защищает программиста от выстрела в жизненно важные органы, причём даже если пациент смертельно болен и для него это стало бы спасением. Но от выстрела в ногу он не защитит.
> Много работал с C/C++ в начале-середине 2000-х, но в некоммерческом применении.Ну... не хочу обидеть, но некоммерческом применение это немного
> На C/C++ можно писать безопасный код.
Но такой код получается только при неограниченном бюджете, типа "запилить марсоход".
> Как результат, на практике практически никто никаких проверок не делает.
И это печально.
> Исторически С был высокоуровневым ассемблером и по сути использовался для более читабельной записи ассемблерного кода. Многие пишущие на C примерно понимали, как будет
> выглядеть ассемблерный код."Примерно" - это правильное определение)
> Именно поэтому там куча undefined behavior: программист писал "a + b" и понимал, что это будет "add a, b", а переполнения будут обрабатываться в зависимости от процессора
Неа. Если бы оно было так, то это было бы Implementation behavior.
А undefined - это вообще "не знаем как оно себя поведет".> Но последнее время (ну, лет 15-20) идёт сильный сдвиг C/C++ (особенно C++) в нишу "прикладных" языков, которые не зависят от железа.
Это началось еще давно, с появления кучи разного железа.
Даже процессоры одного производителя могут иметь разные характеристики.> Если в 80-е программист писал "add a, b" и точно знал, как результат поведёт себя на его конкретной машине,
А как же портируемость)? Это же оплот защитников СИ - мол можно скомпилять под кучу платформ.
О том что оно не факт что будет работать корректно - предпочитают умалчивать).> Rust же изначально был "оторван" от ассемблера и просто предлагает низкоуровневые абстракции, но без привязок к конкретному процессору.
Ага. Потому что сейчас компилятор гораздо лучше оптимизирует код.
Причем "сейчас" это лет 20) Можно вспомнить историю с иксами и раскруткой циклов.> - rust защищает ТОЛЬКО от ошибок работы с памятью; всякие sql-инъекции, логические ошибки и всякое другое он не способен проверить;
Во-1х, ошибки памяти это топ ошибок, как по кол-ву, так и по последствиям.
cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
Memory Corruption - 2341
Overflow - 328Во-2х, логические ошибки можно предотвращать.
Например при помощи системы типов. И паттерн матчинага. И enum type который отличается при сравнении, а не "сравнил крокодилов с апельсинами, фигли там все равно int под капотом".
Ну чтобы не было такого "функция при ошибке возвращает -1, а она вернула -2, все твои данные ушли хакерам".> есть мнение, что rust, защищая от ошибок памяти, расслабляет программиста и отучает его думать и о других ошибках.
Звучит как разговоры старых водил, что с автоматом все разучатся водить)
Или "вы с вашими калькуляторами вообще считать разучитесь!"
> - C/C++ имеют стабильные "релизы" языка; раст же постоянно меняется;Не совсем правда.
У раста есть edition.
doc.rust-lang.org/edition-guide/editions/Которые выходят каждые 3 года и содержат ломающие изменения. Т.е прямой аналог версии С или С++.
В проекте можно зафиксировать версию... и все будет работать даже с последним компилятором.
Например андроид зафиксировал rust 2018.> а C/C++ для "небезопасных" программ будет ещё актуален; хотите постоянно бежать за всё обновляющимся растом или предпочтёте изучить что-то, что ещё долго будет актуальным?
И опять полу правда.
В С++ АБИ частично ломается примерно каждые 3 версии.
Посмотрите статьи про последнии редакции:
Член WG21 пишет что слом АБИ позволяет ускорит некоторые функции на 200-300%.
open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdfНо к сожалению его не послушали.
cor3ntin.github.io/posts/abi/> С другой стороны, сейчас раст слишком сильно форсируется крупными компаниями, этакий systemd.
Форсируется - это как? Они нанимают для своих проектов раст программистов?
Ну так это их право. Возможно они просто устали от бесконечных ошибок.> Есть шанс, что через 10 лет новые проекты на C/C++ начинаться вообще не будут.
Я тоже на это надеюсь.
Было бы классно еще на уровне государства сделать требование "проекты за гос деньги только на безопасных языках".> По ощущениям, раст защищает программиста от выстрела в жизненно важные органы, причём даже если пациент смертельно болен и для него это стало бы спасением.
А можно такой пример?
> Но от выстрела в ногу он не защитит.
Серьезное заявление, требующее доказательств.
В качестве опровержения, я приведу пример андроида
security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.