The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

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

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

Так а какие еще варианты, если язык дефективный by design. Это все-таки дешевле, чем переписывать миллионы легаси кода с C и C++ на Rust.

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Вообще переписывание чего бы то ни было (в том числе на тот же язык) является рефакторингом. Иногда это дешевле поддержки легаси. Иногда нет. Зависит от.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

38. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (4), 04-Авг-25, 12:11 
> Если у нас что-то критичное к безопасности, это означает, что переписать миллион строк на другой язык будет дешевле, чем разгребать последствия

Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано. В этих областях уж точно не сидели бы и не ждали до 202* года, пока им разработчики ГЦЦ/Шланг с барского плеча отсыпят костылей для затыкания дыр в недоязыках из 70-80.

Эти флажки как раз для 95% разработки, где на безопасность наплевать, причем настолько, что они в большинстве случаев даже эти опции компилятора не станут включать под предлогом того, что будут просадки производительности.

Ответить | Правка | Наверх | Cообщить модератору

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

70. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от laindono (ok), 04-Авг-25, 14:06 
> Что-то критичное по безопасности или изначально не писалось на дырявых языках, или уже давно с них переписано.

За примерами далеко не надо ходить:

sudo

Переписали конечно, потихоньку переходят. Но процесс не моментальный.

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

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

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

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

Вы что хотите КАК В ВИНДЕ!?
Линукс создан для страданий и превозмоганий.
Если дать людям удобный способ хотя бы устанавливать ПО нормально, то они расслабятся, размякнут и что потом?
Попросят делать UI/UX хорошо, а не как "бомж вася, по совместительству дизигнер в СПО проекте наблевал на экран" ?

Ответить | Правка | Наверх | 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 намерены добавить режим усиленной безопасности"  –3 +/
Сообщение от Аноним (4), 04-Авг-25, 11:29 
> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.

Это небольшая цена за победу над Растом. Я лично готов и большее терпеть и превозмогать. Надо будет - и ядро буду сам пересобирать с отключенным Растом.

Ответить | Правка | Наверх | Cообщить модератору

25. "В Clang намерены добавить режим усиленной безопасности"  +2 +/
Сообщение от Аноним (-), 04-Авг-25, 11:36 
> Это небольшая цена за победу над Растом.

Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.

> Я лично готов и большее терпеть и превозмогать.

Да без проблем. Терпите и превозмогайте.

> Надо будет - и ядро буду сам пересобирать с отключенным Растом.

Пока дрова на нем не будут писать))
Хотя можно страдать еще больше и сидеть без дров.

Ответить | Правка | Наверх | Cообщить модератору

33. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (4), 04-Авг-25, 11:56 
> Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки.

Я в сишке опции компилятора включу и буду сидеть в безопасности. А чтобы бороться с Растом мне вообще ничего не нужно делать (ну, кроме написания опеннетных комментариев).

> Пока дрова на нем не будут писать))
> Хотя можно страдать еще больше и сидеть без дров

Ой, напугали. Мне чтобы с консолью сношаться эти ваши растовые дрова и не нужны.

Ответить | Правка | Наверх | Cообщить модератору

86. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (86), 04-Авг-25, 14:40 
> "раст не влазит на мой HDD 40GB"

И в чём они неправы?

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

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

16. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (4), 04-Авг-25, 11:22 
> Растоводы кричат что всё пучком

Воут, мерзавцы! Все медленно, гарантий нет, бинари жирные, синтаксис вырвиглазный, неподдерживаемое, абыр, АБЫРВАЛГ111

Ответить | Правка | Наверх | Cообщить модератору

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

58. Скрыто модератором  +/
Сообщение от Аноним (20), 04-Авг-25, 13:20 
Ответить | Правка | Наверх | Cообщить модератору

61. Скрыто модератором  +/
Сообщение от Аноним (-), 04-Авг-25, 13:34 
Ответить | Правка | Наверх | Cообщить модератору

80. Скрыто модератором  +/
Сообщение от Аноним (20), 04-Авг-25, 14:24 
Ответить | Правка | Наверх | Cообщить модератору

36. "В Clang намерены добавить режим усиленной безопасности"  +1 +/
Сообщение от Жироватт (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ообщить модератору

56. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (4), 04-Авг-25, 13:10 
> Мы же не пытаемся отрастить руки у от рождения безруких инвалидов, так ведь?

Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые получают над ними конкурентное преимущество. И с вашей Сишочкой происходит буквально то же самое: еще в начале нулевых она вымерла во всех областях, кроме древнего легаси и embedded, а теперь и в них она окончательно добивается Растом.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

65. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (20), 04-Авг-25, 13:57 
> Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые
> получают над ними конкурентное преимущество.

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

> еще в начале нулевых она вымерла во всех

Выходят стандарты, пишут компиляторы, пишут код на Си, совершают все те же ошибки, ну и никак не помрет. Может у вас другое определение процесса вымирания?

Ответить | Правка | Наверх | Cообщить модератору

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

Он не просил показать код - он просил показать показать пряморуких сишников. А таких в опеннетных комментариях традиционно хоть пруд пруди. 😂

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

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

я вайбкодер, я квадробер :)

Ответить | Правка | Наверх | Cообщить модератору

23. "В Clang намерены добавить режим усиленной безопасности"  –2 +/
Сообщение от Фнон (-), 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ообщить модератору

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

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

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

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

79. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от 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ообщить модератору

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ообщить модератору

88. "В Clang намерены добавить режим усиленной безопасности"  +/
Сообщение от Аноним (-), 04-Авг-25, 14:47 
> Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код?

На такой вопрос тебе никто не сможет ответь на 100%.
Всегда найдется умник с "зачем вы пишете с багами? пишите без багов!".
Но факт того что с С/С++ проблемы перманентные и десятки лет заставляет задуматься)

> Хочу научиться программировать и разрываюсь между С/С++ и Rust.

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

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

Там нет кучи удобных вещей типа Result<value, error> (в С++ появилось в 23 стандарте - expected).
Приходится пробрасывать инты и потом "если -1 то ошибка". А если -2 - то она возможно и не обработается)
Не выглядит ли это просто убого?
Да и приводит к багам, как например тут
opennet.ru/openforum/vsluhforumID3/137136.html#82

> Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.

Проблема в масштабе.
Следить за памятью в проекте из 10к строк легко. А если их будет 100к? Или миллион?
Приходится обмазываться санитайзерами, фаззингом.

Так что лучше выбирай СИшку.
У меня, раст разработчика, будет меньше конкурентов ;)

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру