Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В Clang намерены добавить режим усиленной безопасности"	+/–
Сообщение от opennews (ok), 04-Авг-25, 10:32
Аарон Баллман (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
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "В Clang намерены добавить режим усиленной безопасности"	–11 +/–
Сообщение от laindono (ok), 04-Авг-25, 10:32
А всё почему? А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить.
Ответить | Правка | Наверх | Cообщить модератору

	4. "В Clang намерены добавить режим усиленной безопасности"	–3 +/–
	Сообщение от Аноним (4), 04-Авг-25, 10:42
	> А всё по той причине, что сишечный фронтенд не может что-то адекватное генерировать. Приходится костыли в бекенд ставить. Так а какие еще варианты, если язык дефективный by design. Это все-таки дешевле, чем переписывать миллионы легаси кода с C и C++ на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (11), 04-Авг-25, 11:01
	Дак и не надо всё переписывать. Надо только самое важное.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от фыв (??), 04-Авг-25, 11:17
	Ну вот один в истории так же подумал, а потом слонов через горы повёл.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (35), 04-Авг-25, 12:00
	и он не переписал самое важное, собственно поэтому проект провалился
	Ответить | Правка | Наверх | Cообщить модератору

	132. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (132), 04-Авг-25, 16:24
	Его ошибка в том, что он не реализовал победу при Каннах, а не в потерях при переправе.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	26. "В Clang намерены добавить режим усиленной безопасности"	–4 +/–
	Сообщение от laindono (ok), 04-Авг-25, 11:36
	Зависит от контекста. Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствия эксплуатации дыреней. Вообще переписывание чего бы то ни было (в том числе на тот же язык) является рефакторингом. Иногда это дешевле поддержки легаси. Иногда нет. Зависит от.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	38. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (4), 04-Авг-25, 12:11
	> Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствия Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. В этих областях уж точно не сидели бы и не ждали до 202* года, пока им разработчики ГЦЦ/Шланг с барского плеча отсыпят костылей для затыкания дыр в недоязыках из 70-80. Эти флажки как раз для 95% разработки, где на безопасность наплевать, причем настолько, что они в большинстве случаев даже эти опции компилятора не станут включать под предлогом того, что будут просадки производительности.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от АнонимЪ (?), 04-Авг-25, 14:04
	Для критичной безопасности выбор языка не имеет значения. К слову, для Си есть стандарты безопасного программирования. В прочем, они тоже не имеют значения. Решает формальная верификация кода, а не эти игрища с "мой язык круче".
	Ответить | Правка | Наверх | Cообщить модератору

	96. "В Clang намерены добавить режим усиленной безопасности"	+3 +/–
	Сообщение от Аноним на удаленке (-), 04-Авг-25, 15:17
	Подтверждаю. Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода. Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99 в зависимости от категории надежности ПО. На плюсах доказать что код работает так как положено очень тяжело. Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием(по требованиям низкого уровня), тестированием по требованиям высокого уровня, тестированием  по требованиям комплексным и системным. Ну и пилоты испытатели в конце концов все тестируют на страх и риск. Ну и соответственно самые высокоуровневые тесты не всегда автоматизированы иногда они как протокол ручных манипуляций по приборной панели выполняются. А на уровне модульном и по аысокоуровневым требованиям конечно почти полная автоматизация со сбором покрытия и объяснением почему какое то покрытие не 100%. Пповеряетс как говорится любая операция в коде и последовательность выполнения тоже :). Это дорого и медленно, но вот в авиации лучше пока не придумали.Самолеты от этого не падают каждый раз кстати.  Ну и конечно у нас embedded software а не ваши Intel Xeon с терабайтом ОЗУ. У нас ПЗУ то в десятках мегабайт измеряется на приборах часто а уж ОЗУ и подавно в десятках или сотнях КБ.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от laindono (ok), 04-Авг-25, 14:06
	> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. За примерами далеко не надо ходить: sudo Переписали конечно, потихоньку переходят. Но процесс не моментальный. На счёт флагов компиляции. В 95% кроме оригинального разраба какойто проги/либы никто не знает, что имеет смысл тыкать. Ещё 5% приходится на прошареных пользователей и 0% на мейнтейнеров твоего диструбутива. Тем более, что если ты включил какую-то опцию, это не значит, что код стал быстрее. Это всё надо тестить.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	73. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от АнонимЪ (?), 04-Авг-25, 14:11
	Контрпример: doas.
	Ответить | Правка | Наверх | Cообщить модератору

	97. Скрыто модератором	–1 +/–
	Сообщение от laindono (ok), 04-Авг-25, 15:19
	command not found: doas
	Ответить | Правка | Наверх | Cообщить модератору

	102. Скрыто модератором	+/–
	Сообщение от Аноним (102), 04-Авг-25, 15:23
	> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. Да каеш. Критичное к безопасности, если что, это всё от дырявого насквозь openssl до дырявого насквозь ядра linux с rce во всяких уринах. Даже клоуны от безопасности openbsd принипиально пишут только на C.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	57. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 13:15
	Использования второго языка усложнит сопровождение не в два раз, а кратно! Если бы предлагалось переписать на безопасный, надёжный и верифицируемый язык типа SPARK (ADA), то аргументы можно было ещё принять. А переписывать на ржавый - только испортить простой код.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	64. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от anonymmmeer (?), 04-Авг-25, 13:54
	ещё можно dafny использовать и C код генерить. вообще есть масса возможностей, поэтому раст и не нужен
	Ответить | Правка | Наверх | Cообщить модератору

	66. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 13:58
	> ещё можно dafny использовать и C код генерить. > вообще есть масса возможностей, поэтому раст и не нужен если вы такие умные, то чего  ̶т̶а̶к̶и̶е̶ ̶б̶е̶д̶н̶ы̶е̶ CVE/RCE до сих пор вы дыряшечном коде? (с) Мне как-то в комментах на этом самом форуме СИшник рассказывал, что тесты не нужны, тк он и так знает что пишет, а ждать 10 минуть чтобы PR замерджить это слишком долго)
	Ответить | Правка | Наверх | Cообщить модератору

	68. "В Clang намерены добавить режим усиленной безопасности"	–2 +/–
	Сообщение от laindono (ok), 04-Авг-25, 14:00
	Если ты переписываешь с одного языка на другой, то у тебя остаётся один язык. Очевидно же. > язык типа SPARK (ADA) На сколько сложно собрать команду из десятка программистов на Аде?
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	71. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от АнонимЪ (?), 04-Авг-25, 14:08
	Очевидно что процесс переписывания занимает не один день. И месяцы-годы будет два языка как минимум. Попробуйте найти хорошего специалиста который хорошо знает и C/C++, и Rust. И это пол беды. Если команда состояла преимущественно из сишников, процесс их перехода на раст будет тоже небыстрым. А бизнес простоев не любит. Поэтому будет несколько затянутых процессов одновременно: - переписывание кода на раст; - написание нового кода на раст; - написание нового кода на си (да-да, мы в реальном мире, в котором идеальное не воплощается мгновенно, рук на раст сразу не хватит). Ну, если это серьёзный проект, а не стартап на 1,5 строчки кода.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
	Сообщение от Аноним (77), 04-Авг-25, 14:19
	Эти процессы как раз в firefox можно наблюдать. За эти годы процент кода на rust – 12,3%.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (77), 04-Авг-25, 16:02
	После таких слов стало понятно что вы сударь теоретик. И принимать во внимание комментарии следует соответственно.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	81. Скрыто модератором	+/–
	Сообщение от анонимус (??), 04-Авг-25, 14:25
	Похоже ни для чего кроме переписывания ХРуст не нужон
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

2. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
Сообщение от Аноним (-), 04-Авг-25, 10:33
> Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию. Таких программ единицы. В Gentoo возможно для них прописать отдельные опции сборки в /etc/portage Ставим безопасные опции сборки и пересобираем мир. А rust не нужен.
Ответить | Правка | Наверх | Cообщить модератору

	3. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
	Сообщение от Аноним (4), 04-Авг-25, 10:39
	> В Gentoo > пересобираем мир Гентушникам нет покоя. 😂 Собирай-перекомпиляй!
	Ответить | Правка | Наверх | Cообщить модератору

	5. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 10:43
	Когда правильно собрал перекомпилировать не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (19), 04-Авг-25, 11:24
	А есть люди, которые ставят приложение в пару кликов. Представляете?
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 11:47
	> А есть люди, которые ставят приложение в пару кликов. Представляете? Вы что хотите КАК В ВИНДЕ!? Линукс создан для страданий и превозмоганий. Если дать людям удобный способ хотя бы устанавливать ПО нормально, то они расслабятся, размякнут и что потом? Попросят делать UI/UX хорошо, а не как "бомж вася, по совместительству дизигнер в СПО проекте наблевал на экран" ?
	Ответить | Правка | Наверх | Cообщить модератору

	101. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (101), 04-Авг-25, 15:22
	> Линукс создан для страданий и превозмоганий. Второй десяток лет пользуюсь, и вижу только как страдают виндузятники, то там не работает, то чтото не ставится...а мне надо файлек расшарить, 2 строки в нжинкс, надо снапшот системы сделать - 1 команда, еще одна и скопировал на другой диск...упал впн, 1 команда поднялся другой...блин вот 0 проблем, завернуть сайт почты россии так чтобы он ходил в обход впн, как нефиг, чядн?
	Ответить | Правка | Наверх | Cообщить модератору

	104. Скрыто модератором	+1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 15:28
	Ты все делаешь так) Просто ты не учитываешь годы, потраченные на изучение этих команд и прдолинг с консолькой. Для нормального юзера файл шарится чегез гугл-драйв в тот же 1 клик. Но рассказы про УМВР - это классика красноглазых форумов. Если у вас все работает, то чего появляются темы "Как избавиться от щелчков при запуске приложений на системах с чипами Intel" ? А проблемы с дровами? А с софтом?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (59), 04-Авг-25, 13:25
	> А есть люди, которые ставят приложение в пару кликов. Представляете? Одно приложение? Даже и в пару кликов!!! Эти, даже представить себе не могут, что гентушник, всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир. А Я ОДНИМ нажатием на Enter, могу создать всю систему с нуля, пересобрать мир правильно и создать с него LiveDVD. И с этого LivDVD могу ОДНИМ нажатием на Enter установить готовую собранную систему.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	62. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (62), 04-Авг-25, 13:43
	Никому, кроме тебя, не нужную?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 14:17
	> Эти, даже представить себе не могут, что гентушник, > всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир. Да, нужно только исправить все сломанное в portage. А потом можно пойти попить чай на полдня или даже на день, смотря на каком унитазе он решил попомпилять.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	7. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (7), 04-Авг-25, 10:50
	Ты используешь эти флаги? В частности, - D_FORTIFY_SOURCE=3 интересует. Я читал, он прям сильно роняет производительность
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	8. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (4), 04-Авг-25, 10:52
	> Я читал, он прям сильно роняет производительность Ну, за безопасность нужно платить. Главное, что Раста нет.
	Ответить | Правка | Наверх | Cообщить модератору

	10. "В Clang намерены добавить режим усиленной безопасности"	–3 +/–
	Сообщение от Аноним (10), 04-Авг-25, 11:00
	Раст или так же роняет производительность либо имеет под собой худшую защиту.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В Clang намерены добавить режим усиленной безопасности"	+6 +/–
	Сообщение от Аноним (-), 04-Авг-25, 11:17
	> Раст или так же роняет производительность либо имеет под собой худшую защиту. Нет. В расте за лучшую защиты ты платишь размером временных файлов и временем компиляции во время которого проводятся все проверки - анализ лайфтаймов, владение, типизация и так далее. Вот только программа компилится только один раз, а запускается на порядки больше раз (за исключением гентушников-ноулаферов, которым только дай покомпилять). А рантайм проверки роняют производительность каждому юзеру и для каждого запуска. Но диды продолжаю ныть "раст не влазит на мой HDD 40GB", "лиса компилируется долго", "это нужно целую билдферму делать".
	Ответить | Правка | Наверх | Cообщить модератору

	21. "В Clang намерены добавить режим усиленной безопасности"	–4 +/–
	Сообщение от Аноним (4), 04-Авг-25, 11:29
	> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска. Это небольшая цена за победу над Растом. Я лично готов и большее терпеть и превозмогать. Надо будет - и ядро буду сам пересобирать с отключенным Растом.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В Clang намерены добавить режим усиленной безопасности"	+3 +/–
	Сообщение от Аноним (-), 04-Авг-25, 11:36
	> Это небольшая цена за победу над Растом. Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки. > Я лично готов и большее терпеть и превозмогать. Да без проблем. Терпите и превозмогайте. > Надо будет - и ядро буду сам пересобирать с отключенным Растом. Пока дрова на нем не будут писать)) Хотя можно страдать еще больше и сидеть без дров.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 11:56
	> Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки. Я в сишке опции компилятора включу и буду сидеть в безопасности. А чтобы бороться с Растом мне вообще ничего не нужно делать (ну, кроме написания опеннетных комментариев). > Пока дрова на нем не будут писать)) > Хотя можно страдать еще больше и сидеть без дров Ой, напугали. Мне чтобы с консолью сношаться эти ваши растовые дрова и не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (86), 04-Авг-25, 14:40
	> "раст не влазит на мой HDD 40GB" И в чём они неправы?
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	106. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:29
	> И в чём они неправы? В том, что для каждого времени и для каждого инструмента есть свои требования. HDD 40GB должны остаться где-то... во временах Maxtor, если вы еще помните такую фирму)) Новый инструмент дает новые гарантии, но и просит "оплатить" это требованиями к железу. Если ваше железо не соответствует - это ваша проблема. Вы же не возмущаетесь что современное авто невозможно нормально отремонтировать в гараже? Вот тут аналогичная ситуация.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от выф (?), 04-Авг-25, 11:19
	А можно чуть раскрыть тему для нубов в расте? Растоводы кричат что всё пучком.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	16. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 11:22
	> Растоводы кричат что всё пучком Воут, мерзавцы! Все медленно, гарантий нет, бинари жирные, синтаксис вырвиглазный, неподдерживаемое, абыр, АБЫРВАЛГ111
	Ответить | Правка | Наверх | Cообщить модератору

	47. Скрыто модератором	+/–
	Сообщение от Аноним (47), 04-Авг-25, 12:43
	> А можно чуть раскрыть тему для нубов в расте? > Растоводы кричат что всё пучком. Ну, обычная методичка местных военов против раста. Типа "жирные бинари", "жирный, обязательный рантайм" и прочего. У них даже получалось хелловорлды на расте собирать чуть ли не на десяток МБ, что конечно же служит самым веским доказательством их̵ ̵к̵р̵и̵в̵ы̵х̵ ̵р̵у̵к̵ их тезисов. А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот меньше 1КБ и предложит поискать там рантайм и "жир", можно заявить, что это враки и несчитается и вообще, на си/асме можно еще меньше написать (правда, демонстрировать это военам некогда, им дальше супротив раста воевать надо).
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	51. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (51), 04-Авг-25, 12:56
	> Растоводы кричат что всё пучком. Просто нет на них Дмитрия Пучкова.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

9. "В Clang намерены добавить режим усиленной безопасности"	+/–
Сообщение от Аноним (19), 04-Авг-25, 10:57
Потому что си не умеет безопасно работать с памятью!
Ответить | Правка | Наверх | Cообщить модератору

	12. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Жироватт (ok), 04-Авг-25, 11:08
	Как и ассемблер...
	Ответить | Правка | Наверх | Cообщить модератору

	17. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (19), 04-Авг-25, 11:23
	Ассемблер - это низкоуровневый язык, там это не так зашкварно.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Жироватт (ok), 04-Авг-25, 11:29
	А СИ - ассемблер, где наборы ассемблерных мнемоник просто заменены операторами с автоподстановкой подходящего регистра. Потому трансляторы С->АСМ такие простые и быстрые.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "В Clang намерены добавить режим усиленной безопасности"	–2 +/–
	Сообщение от Аноним (35), 04-Авг-25, 11:55
	значит я могу смело в резюме писать что умею на ассемблере?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от bergentroll (ok), 04-Авг-25, 12:53
	Если вы — транслятор.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 11:23
	> Потому что си не умеет безопасно работать с памятью! Потому что это просто кроссплатформенный ассемблер, который был создан для ускорение портирования юникса и прочего софта с PDP-11 на "более новые" машины. А размер всего юникса того времени был около 100кLOC, что на порядки меньше размеров современных программ (ядро линя - 40MLOC) Но, из-за простоты сишки, отсутствия необходимости думать и того, что на ней писать начать может даже обезьяна, сишка стала ПХП своего времени и вытеснила другие нормальные языки. Результаты чего мы наблюдаем даже через 50 лет.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	84. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (47), 04-Авг-25, 14:37
	> юникса и прочего софта с 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
	Ответить | Правка | Наверх | Cообщить модератору

	20. "В Clang намерены добавить режим усиленной безопасности"	–2 +/–
	Сообщение от Аноним (20), 04-Авг-25, 11:28
	это не молоток не может забивать гвозди и отбивает пальцы, а криворукий, держащий этот молоток :)
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	27. Скрыто модератором	+1 +/–
	Сообщение от Фнон (-), 04-Авг-25, 11:37
	Ты не поверишь, но даже к молотку есть требования) Что-то типа: "Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой части и быть надежно насажены на рукоятки." Т.е если какой-то производитель выпустит молоток, который раз в год  ̶с̶т̶р̶е̶л̶я̶е̶т̶ ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким куском кала пользоваться нельзя. Более того, есть даже правила для  ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶ ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶ защиты: "При работах инструментами ударного действия работники должны пользоваться защитными очками для предотвращения попадания в глаза отлетающих твердых частиц." Так что иди учи уроки, а потом придумай более хорошую аналогию)
	Ответить | Правка | Наверх | Cообщить модератору

	44. Скрыто модератором	–1 +/–
	Сообщение от Аноним (20), 04-Авг-25, 12:34
	> Ты не поверишь, но даже к молотку есть требования) > Что-то типа: > "Слесарные молотки, кувалды должны иметь ровную, слегка выпуклую поверхность бойковой > части и быть надежно насажены на рукоятки." Ну и как эти требования отменяют факт попадания молотком по пальцу? Даже бумажным молотком мы попадем по пальцу при условии криворукости нашей, а не из-за того, что молоток бумажный, а не резиновый. > Т.е если какой-то производитель выпустит молоток, который раз в год  ̶с̶т̶р̶е̶л̶я̶е̶т̶ > ̶в̶ ̶н̶о̶г̶у̶ слетает с ручки прямо в лоб, то таким > куском кала пользоваться нельзя. Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу. Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то. > Более того, есть даже правила для  ̶д̶о̶б̶а̶в̶л̶е̶н̶и̶я̶ > ̶п̶р̶о̶в̶е̶р̶о̶к̶ ̶и̶ ̶с̶а̶н̶и̶т̶а̶й̶з̶е̶р̶о̶в̶ > защиты: > "При работах инструментами ударного действия работники должны пользоваться защитными > очками для предотвращения попадания в глаза отлетающих твердых частиц." В список этих требований еще должны входить всякие требования на гвозди по ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли? > Так что иди учи уроки, а потом придумай более хорошую аналогию) Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :)
	Ответить | Правка | Наверх | Cообщить модератору

	48. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Авг-25, 12:45
	> Ну и как эти требования отменяют факт попадания молотком по пальцу? А при чем тут палец? Вы тут RCE с пальце не сравнивайте) СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу". > Ну это ведь требования ко всем молоткам относится, то что вам по лбу ударит резиновый за место железного, не отменяет факта попадания по лбу. Последствия) От резиновго будет шишка, а от железного можно и ноги протянуть. > Это ведь следствие вашей же криворукости, а не несоблюдение требований каких-то. Если голова молотка закреплена плохо по ТУ производителя - то это просто овняный инструмент. Примерно как СИшка с ее УБ. > В список этих требований еще должны входить всякие требования на гвозди по  ударопрочности и т.д. и контроль самого удара ведь, если вы замахнетесь с "такой силой" (большой), что гвоздь разлетится на куски, то это опять таки ваша КРИВОРУКОСТЬ ведь, вы не можете контролировать свою силу удара, не так ли? Нет не должны. Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью. Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том числе прочность. И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло. В куче отраслей всякие ТБ штуки являются обязательными и никто не будет рассказывать "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий", "от васи осталась горстка пепла не потому что он поленился взять изолирующий ковер, а потому что криворукость". Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется. > Советую вам писать на "вы", ибо бот обращения на "ты" считает за оскорбления :) Ого, это что-то новое.
	Ответить | Правка | Наверх | Cообщить модератору

	58. Скрыто модератором	+/–
	Сообщение от Аноним (20), 04-Авг-25, 13:20
	> А при чем тут палец? > Вы тут RCE с пальце не сравнивайте) > СИшные проблемы вызывают не "я себе пальчик ударил", а "оторвало ногу". Ну это зависит от оценки ущерба (урона, болевой порог и т.д.), в моем посыле это не важно, что удар по пальцу, что по лбу - равносильный урон, больно в любом случае. Я даже не отрицаю случая, что вам даже не будет больно от удара по пальцу, когда вы лишены болевых чувств. Но это не отеняет факта криворукости, а оно определяется именно попаданием молотом по всему (палец, лоб, ногу и т.д.), но не по прямому назначению - гвоздю. > Последствия) > От резиновго будет шишка, а от железного можно и ноги протянуть. То есть, предлагаете забивать гвозди бумажным молотом? Мы же за криворукость говорим, ведь не последствия (боль) определяет криворукость, не "материал" молота, а именно те действия которые приводят к попаданию по пальцу (выше дано определение криворукости). > Если голова молотка закреплена плохо по ТУ производителя - то это просто > овняный инструмент. > Примерно как СИшка с ее УБ. УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ? > Нет не должны. > Тк гвоздь это расходник, то производители расходников должны озаботиться совместимостью. Какой расходник? Это вам не масло (которое кстати тоже подчиняется всяким требованиям), которое надо заменять после отработки ресурса. И в случае сварки электроды - не расходник, а прямое назначение. Может вам производят бумажные гвозди, которые необходимо забивать железным молотом? > Более того, на гозди есть целая серия ГОСТов, которые регламетрируют в том > числе прочность. Ну ударьте с большей силой по гвоздю он разлетится на куски, это разве не криворукость людская, которая не контролирует силу удара? > И вообще попытка свести все на "ваша КРИВОРУКОСТЬ" звучит уныло. Ток аргументы ваши так же звучат уныло. Ударять молотом по пальцу - следствие КРИВОРУКОСТИ! > "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий" Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник. > Дла программинга с его ASS IS стандартов почти нет, но ситуация меняется. Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит. > Ого, это что-то новое. Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить :) Могу ошибаться.
	Ответить | Правка | Наверх | Cообщить модератору

	61. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Авг-25, 13:34
	> УБ определены в стандарте и отдается на волю компилятора. Все вопросы к компилятору, а не к языку. Можете привести пример формально корректного алгоритма с УБ? Только после того как мне показжут язык без компилятора) >> "петровича на вал накрутило не потому что у нас кожух станка убрали, а потому что криворукий" > Все именно так и есть, потому-что он КРИВОРУКИЙ, да еще и глаза залил и не увидел, что кожух скомуниздил его собутыльник. Отлично, а теперь усложним мысленный эксперимент. Пусть на станке не было кожуха никогда. Вот его производителю было плевать -  ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶ петровичи - они ж расходники. Является это инструмент хорошим? Ну или какая-то копейка где нет даже ремней безопасности. Является ли это автомобилем или ведром с гайками? Двойная изоляция в электроинструменте появилась не просто так и стала стандартом. > Ну вот поэтому и даже от кода на расте ничего хорошего при тотальной криворукости ожидать не стоит. У андроидщиков пока все получается. Они даже писали что ошибок по памяти в раст коде за год (ЕМНИП) у них не было ни одной. > Ну комент скринит ASKBOT как я понял из-за этого, когда он видит обращение на "ты" и видать думает, что кто-то кого-то пытается оскорбить > :) Могу ошибаться. Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔 Но тоже могу ошибаться)
	Ответить | Правка | Наверх | Cообщить модератору

	80. Скрыто модератором	+/–
	Сообщение от Аноним (20), 04-Авг-25, 14:24
	> Только после того как мне показжут язык без компилятора) А с чего вы сделали такой вывод? Компилятор следует стандарту языка, язык без компилятора существует, а вот компилятора без языка - нет :) Мне не нужен коредуб, чтобы исполнить какой-нибудь алгоритм, достаточно терминов машины Тьюринга. Язык один, а компиляторов может быть много. > Отлично, а теперь усложним мысленный эксперимент. > Пусть на станке не было кожуха никогда. > Вот его производителю было плевать -  ̶б̶а̶б̶ы̶ ̶н̶а̶р̶о̶ж̶а̶ю̶т̶ > петровичи - они ж расходники. > Является это инструмент хорошим? Если в его инструкции по применению написано "пальцы и другие части тела в данную область не совать", то можно сказать - хороший инструмент. Вопрос в другом, должны ли быть описаны все случаи жизни в этой инструкции? К примеру, в инструкции к применению ядерной бомбы написано - "Не прикуривать" :) Думаю инструкции на все случаи жизни должны быть описаны в стандартах по производству этих инструментов, но а кто перечислил все эти случаи жизни? Говорить, что отныне все компиляторы языков должны автоматически управлять памятью, было бы отлично, но какова цена этого? > Ну или какая-то копейка где нет даже ремней безопасности. Является ли это > автомобилем или ведром с гайками? Это автомобиль по задумке, и по стандартам - отрицать это бред. А по каким стандартам это уже разговор из другой серии. > Двойная изоляция в электроинструменте появилась не просто так и стала стандартом. Почему до сих пор электричество убивает? Почему не придумать стандарт электричества, которое не убивает? Мы должны придумывать стандарты розеток куда нет физ. возможности сунуть пальцы? Или от короткого замыкания перестало происходить возгорание и как следствие - пожары. > У андроидщиков пока все получается. > Они даже писали что ошибок по памяти в раст коде за год > (ЕМНИП) у них не было ни одной. также говорят и пхпешники, которые понятие не имеют, что такое память. > Мне казалось что ASKBOT это когда кто-то жмакает "сообщить модератору" 🤔 > Но тоже могу ошибаться) а возможно, я совсем забыл, что нахожусь в среде где "товарищмайор,разрешитедоложить" это ген :)
	Ответить | Правка | Наверх | Cообщить модератору

	36. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
	Сообщение от Жироватт (ok), 04-Авг-25, 12:05
	Молоток виноват в том, что не распознаёт объект, по которому бьёт и мгновенно не меняет материал бойка: от комка ваты, если там палец, до нейтринного уберкомпактного освинцованного слитка, если это гвоздь. Именно поэтому я смотрю уже три года на все эти споры си-раст-<баззвордязык>, как на битву слабоумных, рассуждающих, что тёплое лучше мягкого потому, что оно зелёное, но в крапинку и кузявее сладкого, но в форме перца с запахом апельсина.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	37. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
	Сообщение от Fracta1L (ok), 04-Авг-25, 12:09
	Покажи пряморуких сишников, которые не ошибаются в работе с памятью. Очень интересно.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	39. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 12:14
	> Покажи пряморуких сишников, которые не ошибаются в работе с памятью. Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю!
	Ответить | Правка | Наверх | Cообщить модератору

	42. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 12:26
	> Я всю жизнь пишу на голых указателях - и никогда проблем не было. Зуб даю! И много у тебя их осталось?))
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+/–
	Сообщение от Аноним (20), 04-Авг-25, 12:37
	> И много у тебя их осталось?)) А много их у тех, кто "грызет гранит науки"? Вот когда вы попробуете "погрызть гранит Си", у вас будет ровно столько "зубов".
	Ответить | Правка | Наверх | Cообщить модератору

	53. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Weders (ok), 04-Авг-25, 13:03
	У нас как у орков в вахе они сами растут) Поэтому и топим за С
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	41. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (20), 04-Авг-25, 12:25
	> Покажи пряморуких сишников ну как показать вам код, который под NDA? Хотя тут надо отвечать вопросом на вопрос, к примеру - "покажи мне код работы с памятью где каждый сишник допустит ошибку (своего рода палающий баг)", но в таком случае баг даже не в работе с памятью, а в архитектуре алгоритма, которая допускает эту "плавучесть", но даже если это одно единственное исключение (исключительная ситуация), всегда можно его отдельно обработать. Так что, при прямых руках и камнем можно забить гвоздь и микроскопом, не отбив пальца.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	45. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 12:36
	> "покажи мне код работы с памятью где каждый сишник допустит ошибку" Так проблема в том, что каждый сишник ошибается немного в другом месте. А результат один и тот же. > ну как показать вам код, который под 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) и состоянием гонки. А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам. Типичные проблемы си и плюсов, несущих родовую травму сишки.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 12:51
	> Так проблема в том, что каждый сишник ошибается немного в другом месте. > А результат один и тот же. Результат некорректного алгоритма - очевиден, и ошибка с памятью это формально некорректный алгоритм. В формально корректном алгоритме по определению нет ошибки, тем более с памятью. > Мы регулярно наблюдаем дыры и взломы проприетарных продуктов с использование buffer overflow, > int overflow, double free и так далее. Ну это говорит только о криворукости не более, кто-нибудь приведет мне пример алгоритма, который всегда будет содержать "int overflow, double free и так далее"? Нет? так в чем дело в Си? На Си нельзя писать формально корректные алгоритмы? > А таких проблем тыщщи. По остальным ссылкам можешь пройтись сам. > Типичные проблемы си и плюсов, несущих родовую травму сишки. Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь? Мы пытаемся их приспособить - протезирование и т.д. Но тем не менее даже в таком случае мы разве должны требовать от них умение жонглирования? Думаю, нет, не логично ибо они ограниченны. Отсюда, если вы всякий раз Сишкой стреляете себе в ногу, то вам не Сишку менять надо на раст, а стоит задуматься над тем, стоит ли заниматься тем где вы ограниченны.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 13:05
	> ошибка с памятью это формально некорректный алгоритм Точно? Или может это проблема в конкретной реализации конкретного алгоритма? > Ну это говорит только о криворукости не более, Проблема в то, что пряморуких сишников не существует. Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки. > На Си нельзя писать формально корректные алгоритмы? На си нельзя два числа сложить чтобы не получить UB)) > Мы же не пытаемся отрастить руки у от рождения безруких инвалидов А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то оно может показаться оскорбительным. > Отсюда, если вы всякий раз Сишкой стреляете себе в ногу, Я себе в ногу не стреляю - я на этом слава богу вообще не пишу. Зато наблюдаю, как с завидной регулярность стреляют другие. И иногда мне отстреливает ногу просто рикошетом. Кстати, раз вы начали про стрельбу - как вы думаете, почему требование наличия предохранителя стало законодательным, а не "по желанию производителя", а в тот же глок добавили аж три предохранителя - trigger safety, firing pin safety и drop safety? Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы. Вот у тут будет так же - 6ыdlокодеры на недоязычке так и не научатся писать без багов с памятью за 40+ лет и из законодательно заставят на нем перестать писать. ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь не быстрая.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 13:50
	>> ошибка с памятью это формально некорректный алгоритм > Точно? Или может это проблема в конкретной реализации конкретного алгоритма? А вы как формально описали память? Выход за границу у вас также формально должен быть описан, и случаи его обработки и т.д. И в итоге у вас и будет формально корректный алгоритм. А реализация - дело техники, хоть на машине Тьюринга, хоть на коредуба, неважно. > Проблема в то, что пряморуких сишников не существует. > Даже диды-аксакАлы, которые пишут в ядро с 1991 года, допускают такие ошибки. Ну как и тех, кто в руках держал молот и ни разу по пальцу не попал. Но это не отменяет того факта, что молотом можно бить по гвоздю и не попадать по пальцу, для этого достаточно быть ПРЯМОРУКИМ! > На си нельзя два числа сложить чтобы не получить UB)) Это к компилятору, а не к языку. > А мне нравится ваше сравнение сишников с безрукими инвалидами. Но осторожней, кому-то > оно может показаться оскорбительным. С коих пор инвалид это оскорбление? Человек ограничен в чем-то и для какой-то работы он по факту инвалид, тут ничего оскорбительного нет. Зачем "заставлять" (байтить) безрукого или с протезами жонглировать? Хочет - пусть жонглирует, но требовать от него это делать как делают профи - маразм! Я не запрещаю криворуким писать на Си, пишите ради Бога. В этом то и суть отличия профи от инвалида (ограниченного в возможностях, способностях), и там где необходимо работа профи - должен работать профи, от этого инвалид оскорбляться не должен, а должен понимать свои ограничения и держаться подальше. > Я себе в ногу не стреляю - я на этом слава богу > вообще не пишу. > Зато наблюдаю, как с завидной регулярность стреляют другие. > И иногда мне отстреливает ногу просто рикошетом. Если вы не профи в грибах и пытаетесь съесть каждый найденный в лесу гриб, то какова вероятность вашего отравления? Такая же аналогия с саперным делом, одна ошибка ценой в жизнь. Какой результат будет от не профи в этой области? > Кстати, раз вы начали про стрельбу - как вы думаете, почему требование > наличия предохранителя стало законодательным, а не "по желанию производителя", а в > тот же глок добавили аж три предохранителя - trigger safety, firing > pin safety и drop safety? > Как раз для того, чтобы из-за дефектности изделия не пострадали случайные мимокрокодилы. Стоп, дефективность изделия - отдельная тема контроля качества (дефектный молот (из сталь другой марки) не обязан всегда по пальцу ударять). В вашем примере предохранитель нужен от случайного выстрела, который по большей части происходил когда тупо оружие роняли из рук на пол. Ну это разве не криворукость на лицо? Ровно поэтому там и скоба есть, прикрывающая спусковой крючок:) > Вот у тут будет так же - 6ыdlокодеры на недоязычке так и > не научатся писать без багов с памятью за 40+ лет и > из законодательно заставят на нем перестать писать. > ЕС и штаты уже идут в этом направлении. Жаль что бюрократия вещь > не быстрая. Людское законодательство - маразм, они вам завтра запретят вообще что-либо писать. Ну как при Екатерине: """ О бытiи помѣщичьимъ людямъ и крестьянамъ въ повиновенiи и послушанiи у своихъ помѣщиковъ, и о неподаванiи челобитенъ въ собственныя Ея Величества руки. """ //ru.wikipedia.org/wiki/Крепостное_право_в_России
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 14:10
	> для этого достаточно быть ПРЯМОРУКИМ! Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет и все)) > Это к компилятору, а не к языку. Нет, именно к языку. Который в недостандарте под названием 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х. Ее уже не исправишь, лучше сразу закопать. > Людское законодательство - маразм Беззаконие или закон божий лучше?))
	Ответить | Правка | Наверх | Cообщить модератору

	87. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 14:42
	> Вот в том то и проблема. Нет пряморуких сишников! Вот просто нет > и все)) Если сишник всю жизнь писал хелловроты он пряморукий? > Нет, именно к языку. Который в недостандарте под названием 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", что мы должны записать в стандарте? >> Людское законодательство - маразм > Беззаконие или закон божий лучше?)) А кто-то уже законы природы отменил? Беззакония по определению нет, если принять за аксиому детерминизм всего бытия.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 15:12
	> Если сишник всю жизнь писал хелловроты он пряморукий? Нет, он просто еще не показал свою криворукость)) > Язык то причем? При том, что это в "стандарте" языка есть UB, а не в компиляторе. > Язык говорит - решай как знаешь Неа, "решай как знаешь" это implementation defined, а не UB. А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так." Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить. То что всякие gcc/clang налепили костылей чтобы результаты жизнедеятельности погромистов можно было хоть как-то скомпилить... ну так это как раз workaround дефективного стандарта. > Стандарт не требует ничего невозможного "Стандарт" не выполняет свою функцию - однозначного определения поведения. > Ну вот давайте конкретно исправим "signed integer overflow", > что мы должны записать в стандарте? Записать однозначное поведение в виде "two's complement wrapping". А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах! Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте. > А кто-то уже законы природы отменил? "Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 15:44
	> При том, что это в "стандарте" языка есть UB, а не в компиляторе. И что? написано ведь "решай как знаешь". > Неа, "решай как знаешь" это implementation defined, а не UB. > А UB - это "x** его знает как оно должно быть, мы договориться не смогли, давайте просто не делайте так." "решай как знаешь" это и есть ""x** его знает как оно должно быть", поэтому ответственность переложили на компилятор, "решай и делай сам, как хочешь". Если бы писаки стандарта пришли бы к какому-то мнению как это разрешить, то они предложили бы и это было бы вовсе не UB как вы заметили. А почему они не предложили, на то есть конкретные причины, надо спросить у писак стандарта. А "implementation defined" - это "делай как хочешь". > Наличие UB вообще делает ваш код "невалидным" и компилятор имеет полное право просто его удалить. UB часть стандарта, и разрешения этой ситуации стандарт переложил на плечи компилятора. > "Стандарт" не выполняет свою функцию - однозначного определения поведения. Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту. > Записать однозначное поведение в виде "two's complement wrapping". > А если нужно что-то другое - то вызывать соответствующие функции (checked, overflowing, saturating и тд). И оно гарантировано будет работать всегда одинаково на всех платформах! Стандарт не обязан это описывать если это тупо решается средствами языка. > Но в теории можно и что-то другое. Главное чтобы оно было ЯВНО прописано в стандарте. На все есть причины, в стандарте если не описаны какие-либо проверки на выходы за границы, это не означает, что их невозможно предотвратить средствами самого языка. > "Закон природы" это твой сосед тебя убил и забрал твою жену. Просто потому что сильнее. кто-то ему может это запретить сделать? А его сосед придет и поступит с ним также, в чем проблема? Природа существует в балансе, нет такого "паразита", который может уничтожить всю природу и т.д. И ни одно существо не способно нарушить этот баланс, то есть законы природы.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 16:04
	> Стандарт это формальность, ни один компилятор не обязан строго следовать стандарту. Ахаха! Бл.... Прям в "Фонд золотых цитат сишников"! А нафига нужен такой стандарт, который "формальность"? У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?)) > в стандарте если не описаны какие-либо проверки на выходы за границы, > это не означает, что их невозможно предотвратить средствами самого языка. Кажется ты не понимаешь. Когда компилятор "видит" UB, то для него это "невозможный" код. Он может его просто выбросить и заменить на no-op. Вот у АДА Спарк нормальный стандарт. Там не только нет UB, но и для того, чтобы называть себя "компилятор языка Ада" нужно пройти проверку на тестовых данных. А для сишки любой кал может назваться "компилятором си". Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 16:23
	> У нас есть стандарт "для колбасы", но производитель "не обязан строго следовать стандарту", поэтому туда можно добавлять туалетную бумагу, мел, крыс, да?)) если потребитель это схавает, то допустимо. Иначе он (потребитель) должен проверить на соответствие этим стандартам, стандарты без проверки - "вилами по воде". > Когда компилятор "видит" UB, то для него это "невозможный" код. Отлично, остановись моя программа, в чем проблема? > Он может его просто выбросить и заменить на no-op. Да ради Бога, замени хоть на хеловрот, в чем проблема? Стандарт вам говорит "решай как хочешь", компилятор "решает" как хочет, так в чем проблема? Проблема в том, что это не совсем то, что вы "хотите"? Так кого это должно волновать то? > А для сишки любой кал может назваться "компилятором си". если реализует язык по описанному стандарту, в чем проблема? > Но на аде писать было сложно, а и 6ыdloкодеры выбрали сишечку. "Преступление и наказание" шедевр не от того, что написана на русском языке!
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	56. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 13:10
	> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь? Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые получают над ними конкурентное преимущество. И с вашей Сишочкой происходит буквально то же самое: еще в начале нулевых она вымерла во всех областях, кроме древнего легаси и embedded, а теперь и в них она окончательно добивается Растом.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	65. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 13:57
	> Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые > получают над ними конкурентное преимущество. Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации больше. И выживает не сильнейший и могучий, а желающий жить. Люди без ног на двух протезах Эвересты покоряют, но не факт, что Эверест покорит самый здоровый человек. И таких примеров много. > еще в начале нулевых она вымерла во всех Выходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет. Может у вас другое определение процесса вымирания?
	Ответить | Правка | Наверх | Cообщить модератору

	99. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 15:21
	> Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то мотивации больше А у девчуль больше мотивации заводить пары с двурукими, чем с безрукими.  В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни. Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг. > Выходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет Ну так я назвал ровно две обоасти, в которых Си пока еще не умер: легаси и встройка (как правило два в одном). Знаете еще хоть одну область, где Си еще жив как основной язык?
	Ответить | Правка | Наверх | Cообщить модератору

	117. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (20), 04-Авг-25, 15:50
	> А у девчуль больше мотивации заводить пары с двурукими, чем с безрукими. А безруких девчуль природа уже отменила? Это что-то из серии про "девочки не пукают"? > В этом-то и загвоздка, дружок: безрукие могут и Эвересты покорять и т.п., но вот только продолжения рода у них нет хоть тресни. Продолжение рода это есть цель такая? > Так же и Сишочкой: можно на "безруком" языке превозмогать и вопреки здравому смыслу совершать подвиги, а можно просто взять нормальный "двурукий" инструмент и не любить себе мозг. Подмена понятий, "безрукий" - человек, а не язык. > Знаете еще хоть одну область, где Си еще жив как основной язык? я не знаю, что такое "легаси", дайте определение.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 13:04
	>> Покажи пряморуких сишников > ну как показать вам код, который под NDA? Он не просил показать код - он просил показать показать пряморуких сишников. А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	67. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 13:59
	> Он не просил показать код - он просил показать показать пряморуких сишников. > А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂 я вайбкодер, я квадробер :)
	Ответить | Правка | Наверх | Cообщить модератору

	100. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Fracta1L (ok), 04-Авг-25, 15:22
	Я не могу проверить, действительно ли сишный код под NDA так хорош, так что для меня это из разряда веры, я знаю только, что из открытых проектов на сишке примерно все имеют в анамнезе ошибки работы с памятью.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	119. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 15:52
	> Я не могу проверить, действительно ли сишный код под NDA так хорош ну а мне как проверить, действительно ли "прямые" руки у программиста?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Fracta1L (ok), 04-Авг-25, 15:56
	Твоё мнение насчёт прямоты рук не имеет практического смысла, факт в том, что примерно все сишки не могут писать код без ошибок типа use-after-free, так что если на уровне языка можно избавиться от таких ошибок - это очень здорово.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 16:31
	> что примерно все сишки не могут писать код без ошибок типа use-after-free, так, что если на уровне языка можно избавиться от таких ошибок - это очень здорово. Ну избавились мы от этого и получили что? Раст? Какое средство языка си мешает избавлению от use-after-free? Тупо незнания со стороны программиста устройство памяти и ее контроля, и все! Все кто топит за то, чтобы это все делал за них компилятор - просто не знают как это решать, я другого объяснения не вижу. > это очень здорово было бы здорово, когда мне не будет необходимости вообще писать программы, пусть этим неблагодарным делом занимается другая программа, написанная один раз более "умелым" программистом.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 16:43
	> Ну избавились мы от этого и получили что? Раст? Ага, язык нового поколения, который пытается исправить недостатки предыдущего) > Какое средство языка си мешает избавлению от use-after-free? Никакое. > Тупо незнания со стороны программиста устройство памяти и ее контроля, и все! Все кто топит за то, чтобы это все делал за них компилятор - просто не знают как это решать, я другого объяснения не вижу. А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?
	Ответить | Правка | Наверх | Cообщить модератору

23. "В Clang намерены добавить режим усиленной безопасности"	–4 +/–
Сообщение от Фнон (-), 04-Авг-25, 11:31
Эх, сколько телодвижений для исправления того, что ущербно с даты создания. Зато потом читаем клевую TEH DRAMA комитета по внедрению SafeC++. А ведь достаточно взять простой ржавый...
Ответить | Правка | Наверх | Cообщить модератору

	29. "В Clang намерены добавить режим усиленной безопасности"	+3 +/–
	Сообщение от Аноникл (?), 04-Авг-25, 11:47
	достаточно взять ржавый и начать писать extern "C" потому что без сишного ABI он никому не нужен
	Ответить | Правка | Наверх | Cообщить модератору

	43. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 12:28
	> достаточно взять ржавый и начать писать extern "C" > потому что без сишного ABI он никому не нужен Плюсы без extern "C" тоже мало кому нужны. Но это как раз стиму выбросить сишку отовсюду откуда возможно. И все писать на расте))
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (35), 04-Авг-25, 13:32
	Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (47), 04-Авг-25, 15:13
	> Это просто невозможно, у 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))
	Ответить | Правка | Наверх | Cообщить модератору

	103. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (4), 04-Авг-25, 15:25
	> Это просто невозможно, у Rust нет собственного ABI Ты не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте.
	Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

	107. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:30
	> Ты не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы. Если не веришь, то попробуй найти его упоминания в сишочном стандарте. Ты просто бьешь ниже пояса! Или ты надеялся, что хотя бы половина местных 🤡 хотя бы открывала текст стандарта? Зря мой друг, очень зря)
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (51), 04-Авг-25, 12:58
	... и просто выбросить.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

74. "В Clang намерены добавить режим усиленной безопасности"	+/–
Сообщение от Аноним (74), 04-Авг-25, 14:15
Режим, при котором для компиляции программы нужно будет проходить KYC (шутка).
Ответить | Правка | Наверх | Cообщить модератору

76. "В Clang намерены добавить режим усиленной безопасности"	+/–
Сообщение от xsignal (ok), 04-Авг-25, 14:18
Си - сила! Лучший язык программирования. И не стоит на месте, а развивается, не ломая совместимость при этом. А все нападки на Си - спланированная и оплаченная кампания по дескридитации с целью вытеснить независимых разработчиков из мира свободного ПО.
Ответить | Правка | Наверх | Cообщить модератору

	109. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (101), 04-Авг-25, 15:31
	Рептилоиды придумали раст, чтобы подсадить на него человечество извести сишников, и больше никогда человечество не смогло вернуться к гнутым истокам как завещали наши великие предки. > спланированная и оплаченная Зачем дурачкам платить, дурачки за просто так будут в лепешку расшибаться чтобы доказать чтото.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от xsignal (ok), 04-Авг-25, 15:40
	> чтобы подсадить на него человечество извести сишников Да, подсадная утка, 100%!
	Ответить | Правка | Наверх | Cообщить модератору

	116. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 15:49
	> И не стоит на месте, а развивается, не ломая совместимость при этом. Аж жЫр с монитора потек. > кампания по дескридитации Никто не дискредитирует сишников так хорошо как сами сишники. > оплаченная Не правда! Я абсолютно без-воз-мезд-но, то есть даром (с) и с огромным удовольствием пишу про сишные дырени везде где можно. Ведь многие люди не знают про опасность, которую таит в себе 6ыdloкод не небезопасном йазычке из 70х! А потом они удивляются как их телегу ломают просто прислав "специально оформленное изображение". Люди просто должны об этом знать, думать об этом, писать своему депутату "а вдруг в этом авто используется опасный код?!" и требовать запрета небезопасных языков. И по последним изменениям видно, что эта деятельность дает свои плоды.
	Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

	123. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от xsignal (ok), 04-Авг-25, 15:57
	> Никто не дискредитирует сишников так хорошо как сами сишники Весь лучший базовый софт, за счёт которого ещё не рушится, не смотря на все старания некоторых, а прочно стоит огромное здание современного IT, написан на Си.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 16:09
	> Весь лучший базовый софт А давай посчитаем, какой софт написан на сишечке, а какой на c++. С чего начнем? С компиляторов? Оба два оптимизирующих на с++. С ос? Видна это с++ и даже раст, макось - обжси. С офисных пакетов? Там нет сишечки. Может игрульки? На сишке нет ни одного современного движка. Так что написано на си, кроме ядра линя и то, только потому что фин не признает своих ошибок? > прочно стоит огромное здание современного IT, написан на Си. "Прочно" стоит на шатком фундаменте дырявейших поделий вроде libxml2)))
	Ответить | Правка | Наверх | Cообщить модератору

	133. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от xsignal (ok), 04-Авг-25, 16:27
	> С чего начнем? Да хотя бы Apache и nginx - несущие платформы всего сегодняшнего интернета! И с этим они более чем отлично справляются, и Си никак не мешает, если голова на плечах есть.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от xsignal (ok), 04-Авг-25, 16:37
	> Видна это с++ и даже раст Ахаха) Ну с этим глюкодромом всё понятно, хороший антипример!)
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

78. "В Clang намерены добавить режим усиленной безопасности"	+/–
Сообщение от Аноним (78), 04-Авг-25, 14:19
Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код? Хочу научиться программировать и разрываюсь между С/С++ и Rust. Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.
Ответить | Правка | Наверх | Cообщить модератору

	79. "В Clang намерены добавить режим усиленной безопасности"	+2 +/–
	Сообщение от xsignal (ok), 04-Авг-25, 14:24
	Ни на каком языке невозможно писать безопасный код - это архитектурный изъян человеческого мозга. Можно встроить в язык кучу костылей, которые снизят риск ошибок при работе с памятью, но это никак не поможет от совершения логических ошибок, которые приводят к уязвимостям.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Rev (ok), 04-Авг-25, 14:28
	В случае с С/С++ это человеческий фактор, так как компилятор ни о чём не предупреждает. А в Rust компилятор все спорные ситуации покажет и откажется такой код компилировать. Я, как ленивая жопа, предпочитаю писать на Расте, так как это требует меньше когнитивных напряжений.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	90. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (78), 04-Авг-25, 14:52
	То есть, технически возможно писать безопасный код на С/С++? Все верно?
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В Clang намерены добавить режим усиленной безопасности"	–2 +/–
	Сообщение от Аноним (47), 04-Авг-25, 15:34
	> То есть, технически возможно писать безопасный код на С/С++? Все верно? Технически, можно переделать стиральную машину или холодильник в космический корабль или подводную лодку, все верно.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (101), 04-Авг-25, 15:41
	Бензопила это безопасный инструмент? Допустим что да, тогда отбиться ей от нашествия зомби нельзя, а значит она не нужна Допустим что нет, и маньяк может запилить десяток человек забежав на детский утренник, а значит она не нужна. Пользуйтесь пилкой для ногтей От зомби не поможет никак, но можно засадить комуто в глаз..но так их сейчас из пенопласта делают, абсолютно безопасная, но можно ее порезать и устроить так чтобы ктото задохнулся..но задушить можно и руками, черт. абсолютно безопасно только то чего не существует, но идеи убивают похлеще всяких оружий...то есть технически..ну вы поняли
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	83. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от анонимус (??), 04-Авг-25, 14:28
	То что возможно сломать будет сломано
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	85. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 14:38
	> С/С++ Нет такого языка. Есть Си, а есть С++ (на котором можно писать как на си, но не надо так!) Внимательность человека это тоже ресурс и он конечен. У кого-то больше, у кого-то меньше, но всегда наступает момент когда человек допускает ошибку. Поэтому намного лучше выбирать язык, где тупые и рутинные действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное - логику программы. Современный с++ неплох, начиная наверное с с++17. Но наследственные дефекты си в нем остались. Писать нормально на нем можно, но довольно сложно и "дорого". Можно почитать какой ценой досталась надежность напр. llvm, сколько человекочасов они потратили на тесты, фаззинг, санитайзеры и так далее.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	89. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (78), 04-Авг-25, 14:51
	Прямо указал что языки, а не язык.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 14:53
	> Поэтому намного лучше выбирать язык, где тупые и рутинные > действия проверяет компилятор, чтобы расходовать свою внимательность на что-то более важное > - логику программы. с каких пор программирование это рутина? вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и боитесь в какой-то момент по невнимательности допустить всякого рода целочисленных переполнений? От такой рутины должен спасть вас язык, компилятор и т.д.? Я вот  думаю вы вовсе не программированием занимаетесь, а как сами описали - рутиной.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	98. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:20
	> с каких пор программирование это рутина? А где там написано что "программирование это рутина"? Там написано про рутинные действия в рамках программирования. Это огромная разница. В любой работе есть рутинные элементы, а есть творческие. Даже в художке - подготовка холста, мойка кисточек и тд - это рутина. И кстати именно поэтому многие просто покупают готовых холст в магазе или автомойку для кисточек - они не хотят тратить свое время на ерунду, а хотят творить. Вот раньше диды в vi писали код, и имя каждой переменной/функции полностью вписывали. А сейчас эту рутину делает IDE в виде автодополнения. > вы каждый раз заново пишите, допустим алгоритм сложения двух чисел и > боитесь в какой-то момент по невнимательности допустить всякого рода > целочисленных переполнений Не боюсь потому что в нормальных языках там нет проблемы. А в "особенных" нужно задумываться "а что будет если будет переполнение?", "а как именно оно будет реализовано?", а "что если компилятор будет другой? или версия обновится?"
	Ответить | Правка | Наверх | Cообщить модератору

	114. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (86), 04-Авг-25, 15:46
	> А сейчас эту рутину делает IDE в виде автодополнения Я вспомнил об этом 10 лет назад, когда в одной отечественной cms неправильно писал название функции getTreeStucture и не понимал, почему оно её не находит. Оказалось, потому что я писал её без автодополнения и без ошибки как getTreeStructure, а разработчики этой cms один раз написали неправильно а потом только автодополняли. Лучший способ не допустить ошибку - это скрыть ошибку.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:55
	А в чем ошибка-то? Опечатка в имени функции никак не влияет на то, во что эта функция скомпилится. Оно никак не влияет на работу программы.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 16:41
	> А где там написано что "программирование это рутина"? > Там написано про рутинные действия в рамках программирования. Это огромная разница. #include <stdio.h> рутина? > Даже в художке - подготовка холста, мойка кисточек и тд - это рутина. И кстати именно поэтому многие просто покупают готовых холст в магазе или автомойку для кисточек - они не хотят тратить свое время на ерунду, а хотят творить. #include <stdio.h> - ерунда? зачем тратить на это время, особенно всякие макросы в языке. Я вообще не воспринимаю языки с макросами в том числе и Си. Рутина за которую вы говорите и есть достижение идеала в собственных действиях, оттачивание мастерства, а как без повторения оттачивать их до идеала? Как нарисовать шедевр на холсте низкого качества? Чтобы создавать шедевры, там все должно быть идеальным, каждый шаг который вы считаете рутиной. > А сейчас эту рутину делает IDE в виде автодополнения. А зачем мне это нужно будет во времена когда какой-то ЫЫ за меня все это будет генерировать?   > А в "особенных" нужно задумываться "а что будет если будет переполнение?", "а как именно оно будет реализовано?", а "что если компилятор будет другой? или версия обновится?" Если вам не надо об этом задумываться, то зачем вам вообще думать о программе, пусть ЫЫ пишет код. Ровно это и нужно, чтобы человек тупо перестал думать. Ок, ваше право.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	115. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (101), 04-Авг-25, 15:48
	Отлично. > чтобы расходовать свою внимательность на что-то более важное - логику программы. Ок, допустим внимательности Х - const, и за 3 дня человек допускает Y ошибок, тогда логичнее их допустить в рутинных вещах, изза которых программа либо не собирется, либо не запустится, что укажет на ошибку, чем через 10 лет обнаружить, что логика кривая.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	120. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:53
	> тогда логичнее их допустить в рутинных вещах, из-за которых > программа либо не собирется, либо не запустится, Именно. Вот только это про раст, а не про си. Ты накосячил - компилятор просто не скомпилит это. А сишку он скомпилит, запустит, а потом через Т лет окажется что 28 backspace позволяют обойти ввод пароля. > чем через 10 лет обнаружить, что логика кривая. Да, именно так! Поэтому лучше тратить внимательность на логику, а не на ерунду.
	Ответить | Правка | Наверх | Cообщить модератору

	124. Скрыто модератором	+/–
	Сообщение от Аноним (86), 04-Авг-25, 15:57
	> лучше тратить внимательность на логику, а не на ерунду. Я без предъяв, но вы не рассматриваете вариант, что тратя внимательность на ерунду я эту самую внимательность развиваю?
	Ответить | Правка | Наверх | Cообщить модератору

	130. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Авг-25, 16:13
	> тратя внимательность на ерунду я эту самую внимательность развиваю? Возможно. Но ты ее точно также развиваешь, тратя не на ерунду. И этой неерунды ты сможешь сделать намного больше до первой ошибки. Плюс там есть гарантии, что за тебя проверят и сообщат "если что".
	Ответить | Правка | Наверх | Cообщить модератору

	88. "В Clang намерены добавить режим усиленной безопасности"	–1 +/–
	Сообщение от Аноним (-), 04-Авг-25, 14:47
	> Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код? На такой вопрос тебе никто не сможет ответь на 100%. Всегда найдется умник с "зачем вы пишете с багами? пишите без багов!". Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься) > Хочу научиться программировать и разрываюсь между С/С++ и Rust. Если у тебя нет образования, я бы начал с алгоритмов и структур данных. Потому что если у тебя будет фундамент - то в общем-то не так сложно переходить с одного языка на другой. Плюсы еще может имеют смысл - на них пишется много геймдева, пользовательского и научного софта. СИшка уже безбожно устарела, только легаси и проектры от неосиляторов. Там нет кучи удобных вещей типа Result<value, error> (в С++ появилось в 23 стандарте - expected). Приходится пробрасывать инты и потом "если -1 то ошибка". А если -2 - то она возможно и не обработается) Не выглядит ли это просто убого? Да и приводит к багам, как например тут opennet.ru/openforum/vsluhforumID3/137136.html#82 > Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй. Проблема в масштабе. Следить за памятью в проекте из 10к строк легко. А если их будет 100к? Или миллион? Приходится обмазываться санитайзерами, фаззингом. Так что лучше выбирай СИшку. У меня, раст разработчика, будет меньше конкурентов ;)
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	92. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от xsignal (ok), 04-Авг-25, 15:09
	> Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься) У любого языка, который много лет используется для написания тонн кода, вскроются "перманентные проблемы на десятки лет") "Ошибок нет только у того, кто ничего не делает".
	Ответить | Правка | Наверх | Cообщить модератору

	95. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 15:14
	> У любого языка, который много лет используется для написания тонн кода, вскроются  "перманентные проблемы на десятки лет") И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа? Или может у АДА есть проблемы уровня "28 раз нажал бекспейс - пропустил введение пароля"? Ненадо оправдывать бракованные недоязычки. > "Ошибок нет только у того, кто ничего не делает". А что делает тот, кто совершает одни и те же ошибки из года в год? Знаешь, что такое безумие? (с)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от xsignal (ok), 04-Авг-25, 15:29
	> И какие проблемы, с таким импактом CVE/RCE есть у джавы или шишарпа? Всё есть, логические ошибки есть везде. > А что делает тот, кто совершает одни и те же ошибки из года в год? В том, что ошибки обнаруживаются, нет ничего плохого - значит, тесты работают! Плохо, когда ошибок "как-будто нет" (их просто замаскировал "умный" компилятор), а потом эти скрытые логически ошибки, не обнаруживаемые тестами, приводят к катастрофическим последствиям...
	Ответить | Правка | Наверх | Cообщить модератору

	118. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (86), 04-Авг-25, 15:51
	> А что делает тот, кто совершает одни и те же ошибки из года в год? Имеете ввиду тот, кто из года в год придумывает всё новые "безопасные" языки, которые уж на этот-то раз точно избавят программиста от ошибок? Ну, раз вы спросили, лично я думаю, что они это не для каких-то целей делают а просто потому что им захотелось создать новый язык с какой-нибудь фишкой. У кого-то это байткод и своя виртуальная машина размером с реальную, у кого-то отступы пробелами, у кого-то интерпретатор угадывающий нужна ли здесь точка с запятой или нет, у кого-то прикольный синтаксис, у кого-то компилируемость и при этом бинарник HelloWorld в несколько мегабайт.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	129. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (20), 04-Авг-25, 16:10
	> А что делает тот, кто совершает одни и те же ошибки из года в год? > Знаешь, что такое безумие? (с) Криворукость сишников никто не отменял, но из этого не может следовать, что на си нельзя писать корректные "прямые" программы. По безумцам в обществе нельзя судить о пандемии, она должна носить тотальный характер.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	108. "В Clang намерены добавить режим усиленной безопасности"	+1 +/–
	Сообщение от Аноним (86), 04-Авг-25, 15:30
	Много работал с 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++ начинаться вообще не будут. По ощущениям, раст защищает программиста от выстрела в жизненно важные органы, причём даже если пациент смертельно болен и для него это стало бы спасением. Но от выстрела в ногу он не защитит.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	126. "В Clang намерены добавить режим усиленной безопасности"	+/–
	Сообщение от Аноним (-), 04-Авг-25, 16:02
	> Много работал с 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.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема