forum.opennet.ru - "В Clang намерены добавить режим усиленной безопасности" (181)

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

Оглавление

А всё почему А всё по той причине, что сишечный фронтенд не может что-то адеква, laindono (ok), 10:32 , 04-Авг-25, (1) –11

Так а какие еще варианты, если язык дефективный by design Это все-таки дешевле,, Аноним (4), 10:42 , 04-Авг-25, (4) –4

Дак и не надо всё переписывать Надо только самое важное , Аноним (11), 11:01 , 04-Авг-25, (11)

Ну вот один в истории так же подумал, а потом слонов через горы повёл , фыв (??), 11:17 , 04-Авг-25, (14)

и он не переписал самое важное, собственно поэтому проект провалился, Аноним (35), 12:00 , 04-Авг-25, (35)
Его ошибка в том, что он не реализовал победу при Каннах, а не в потерях при пер, Аноним (132), 16:24 , 04-Авг-25, (132)

Зависит от контекста Если у нас что-то критичное к безопасности, это означает, , laindono (ok), 11:36 , 04-Авг-25, (26) –6

Что-то критичное по безопасности или изначально не писалось на дырявых языках, и, Аноним (4), 12:11 , 04-Авг-25, (38)

Для критичной безопасности выбор языка не имеет значения К слову, для Си есть с, АнонимЪ (?), 14:04 , 04-Авг-25, (69)

Подтверждаю Работаю в гражданской авиации где есть авиационные стандарты на вер, Аноним на удаленке (-), 15:17 , 04-Авг-25, (96) –1

Я сильно сомневаюсь, что бы работаете в гражданской авиации, ибо там десятилетия, Аноним (4), 17:10 , 04-Авг-25, (150) +3

Ну, т е проверенно безопасный язык существует езё, aname (?), 20:31 , 04-Авг-25, (183)
Ну, т е проверенно безопасный язык существует уже десятилетия и работает Т е , aname (?), 20:32 , 04-Авг-25, (185)

За примерами далеко не надо ходить sudoПереписали конечно, потихоньку переходят , laindono (ok), 14:06 , 04-Авг-25, (70) –2

Контрпример doas , АнонимЪ (?), 14:11 , 04-Авг-25, (73) +1

command not found doas, laindono (ok), 15:19 , 04-Авг-25, (97) –2
Скрыто модератором, Аноним (-), 19:36 , 04-Авг-25, (169)

Да каеш Критичное к безопасности, если что, это всё от дырявого насквозь openss, Аноним (102), 15:23 , 04-Авг-25, (102)

Использования второго языка усложнит сопровождение не в два раз, а кратно Если б, Аноним (-), 13:15 , 04-Авг-25, (57)

ещё можно dafny использовать и C код генерить вообще есть масса возможностей, по, anonymmmeer (?), 13:54 , 04-Авг-25, (64)

если вы такие умные, то чего 822 т 822 а 822 к 822 и 822 е 822 822 б , Аноним (-), 13:58 , 04-Авг-25, (66) –1

Зачем ты пишешь дыряшечный код, а ответственность перекладываешь на других , aname (?), 20:35 , 04-Авг-25, (186)

Если ты переписываешь с одного языка на другой, то у тебя остаётся один язык Оч, laindono (ok), 14:00 , 04-Авг-25, (68) –2

Очевидно что процесс переписывания занимает не один день И месяцы-годы будет дв, АнонимЪ (?), 14:08 , 04-Авг-25, (71) +1

Эти процессы как раз в firefox можно наблюдать За эти годы процент кода на rust, Аноним (77), 14:19 , 04-Авг-25, (77) +2

После таких слов стало понятно что вы сударь теоретик И принимать во внимание к, Аноним (77), 16:02 , 04-Авг-25, (125)

упоминать в одном предложении си и бекенд фронтент - кричать о своём диагнозе в, 12yoexpert (ok), 20:32 , 04-Авг-25, (184)

Таких программ единицы В Gentoo возможно для них прописать отдельные опции сбор, Аноним (-), 10:33 , 04-Авг-25, (2) +2

Гентушникам нет покоя 128514 Собирай-перекомпиляй , Аноним (4), 10:39 , 04-Авг-25, (3) +3

Когда правильно собрал перекомпилировать не надо , Аноним (-), 10:43 , 04-Авг-25, (5)

А есть люди, которые ставят приложение в пару кликов Представляете , Аноним (19), 11:24 , 04-Авг-25, (19)

Вы что хотите КАК В ВИНДЕ Линукс создан для страданий и превозмоганий Если дать, Аноним (-), 11:47 , 04-Авг-25, (30) +1

Второй десяток лет пользуюсь, и вижу только как страдают виндузятники, то там не, Аноним (101), 15:22 , 04-Авг-25, (101)

Ты все делаешь так Просто ты не учитываешь годы, потраченные на изучение этих ко, Аноним (-), 15:28 , 04-Авг-25, (104) +2

Текстовый вархаммер , aname (?), 20:37 , 04-Авг-25, (188)

Одно приложение Даже и в пару кликов Эти, даже представить себе не могут, что, Аноним (59), 13:25 , 04-Авг-25, (59)

Никому, кроме тебя, не нужную , Аноним (62), 13:43 , 04-Авг-25, (62) +1

Это ржавый не нужен, а моя система нужна всем https www opennet ru openforum , Аноним (-), 16:51 , 04-Авг-25, (139)

Твоя система нужна полторым землекопам А раст используют большая часть топовых ф, Аноним (-), 19:37 , 04-Авг-25, (171)

Да, нужно только исправить все сломанное в portage А потом можно пойти попить ча, Аноним (-), 14:17 , 04-Авг-25, (75)

Ну с Rust ситуация еще хуже, так как нет стабильного ABI Там для новой версии к, ptr (ok), 19:57 , 04-Авг-25, (176)

Разве у C есть какое-то ABI Что-то в стандарте я такого не видел C как-то с э, Аноним (-), 20:13 , 04-Авг-25, (178)

Посмотрите внимательно на диск своего компьютера Все dll so в нем используют од, ptr (ok), 20:26 , 04-Авг-25, (180)

Ты используешь эти флаги В частности, - D_FORTIFY_SOURCE 3 интересует Я читал,, Аноним (7), 10:50 , 04-Авг-25, (7)

Ну, за безопасность нужно платить Главное, что Раста нет , Аноним (4), 10:52 , 04-Авг-25, (8) +1

Раст или так же роняет производительность либо имеет под собой худшую защиту , Аноним (10), 11:00 , 04-Авг-25, (10) –4

Нет В расте за лучшую защиты ты платишь размером временных файлов и временем ко, Аноним (-), 11:17 , 04-Авг-25, (13) +6

Это небольшая цена за победу над Растом Я лично готов и большее терпеть и прево, Аноним (4), 11:29 , 04-Авг-25, (21) –5

Вы готовы бороться с растом, а лучше бы боролись с дырявостью сишки Да без пробл, Аноним (-), 11:36 , 04-Авг-25, (25) +3

Я в сишке опции компилятора включу и буду сидеть в безопасности А чтобы боротьс, Аноним (4), 11:56 , 04-Авг-25, (33)

И в чём они неправы , Аноним (86), 14:40 , 04-Авг-25, (86)

В том, что для каждого времени и для каждого инструмента есть свои требования HD, Аноним (-), 15:29 , 04-Авг-25, (106) –2

Ещё раз Гарантии безопасности в C, C даются при исполнении программы И от рж, Аноним (-), 18:08 , 04-Авг-25, (161) –2

О как Правильные ОС и ядра у нас поди на чистой магии работают , Аноним (164), 18:38 , 04-Авг-25, (164) –1

Не на магии, а на спец инструкция процессоров и действительно ядра OS могут отла, Аноним (-), 19:20 , 04-Авг-25, (167)

Цена этого - или многократное дублирование кода при статическом связывании, или , ptr (ok), 20:13 , 04-Авг-25, (177)

Но все внутренние проверки и гарантии останутся Т е будет какое-то unsafe связыв, Аноним (-), 20:20 , 04-Авг-25, (179)

А можно чуть раскрыть тему для нубов в расте Растоводы кричат что всё пучком , выф (?), 11:19 , 04-Авг-25, (15)

Воут, мерзавцы Все медленно, гарантий нет, бинари жирные, синтаксис вырвиглазны, Аноним (4), 11:22 , 04-Авг-25, (16)
Ну, обычная методичка местных военов против раста Типа жирные бинари , жирный, Аноним (47), 12:43 , 04-Авг-25, (47)
Просто нет на них Дмитрия Пучкова , Аноним (51), 12:56 , 04-Авг-25, (51)
https www opennet ru openforum vsluhforumID3 137467 html 310 после этого поста, Аноним (-), 17:19 , 04-Авг-25, (152) –2

Громкое заявление А как же гарантии и проверки на этапе компиляции Которые прове, Аноним (-), 17:36 , 04-Авг-25, (153)

В C, C гарантии безопасности не даются только одним компилятором Хотя сегодня, Аноним (-), 17:53 , 04-Авг-25, (157) –1

То есть проактивная защита CPU и ядро OS гарантированно защищают программы, на, Аноним (4), 17:56 , 04-Авг-25, (158) +2

Проактивная защита CPU ядро OS дадут гарантии безопасности и корректности рабо, Аноним (-), 18:54 , 04-Авг-25, (165) –1

Флаги безопасности не сильно роняют производительность, там проценты, в парах ес, Аноним (-), 17:06 , 04-Авг-25, (149)

Потому что си не умеет безопасно работать с памятью , Аноним (19), 10:57 , 04-Авг-25, (9) +1

Как и ассемблер , Жироватт (ok), 11:08 , 04-Авг-25, (12) +1

Ассемблер - это низкоуровневый язык, там это не так зашкварно , Аноним (19), 11:23 , 04-Авг-25, (17)

А СИ - ассемблер, где наборы ассемблерных мнемоник просто заменены операторами с, Жироватт (ok), 11:29 , 04-Авг-25, (22)

значит я могу смело в резюме писать что умею на ассемблере , Аноним (35), 11:55 , 04-Авг-25, (32) –2

Если вы 8212 транслятор , bergentroll (ok), 12:53 , 04-Авг-25, (50) +1

Потому что это просто кроссплатформенный ассемблер, который был создан для ускор, Аноним (-), 11:23 , 04-Авг-25, (18) –1

100кLOC, это уже V7 Меньше PDP-7https github com dspinellis unix-history-repo, Аноним (47), 14:37 , 04-Авг-25, (84)

это не молоток не может забивать гвозди и отбивает пальцы, а криворукий, держащи, Аноним (20), 11:28 , 04-Авг-25, (20) –2

Скрыто модератором, Фнон (-), 11:37 , 04-Авг-25, (27) +2

Скрыто модератором, Аноним (20), 12:34 , 04-Авг-25, (44) –1

Скрыто модератором, Аноним (-), 12:45 , 04-Авг-25, (48)

Скрыто модератором, Аноним (20), 13:20 , 04-Авг-25, (58)

Скрыто модератором, Аноним (-), 13:34 , 04-Авг-25, (61)

Скрыто модератором, Аноним (20), 14:24 , 04-Авг-25, (80)

Молоток виноват в том, что не распознаёт объект, по которому бьёт и мгновенно не, Жироватт (ok), 12:05 , 04-Авг-25, (36) +2
Покажи пряморуких сишников, которые не ошибаются в работе с памятью Очень интер, Fracta1L (ok), 12:09 , 04-Авг-25, (37) +2

Я всю жизнь пишу на голых указателях - и никогда проблем не было Зуб даю , Аноним (4), 12:14 , 04-Авг-25, (39)

И много у тебя их осталось , Аноним (-), 12:26 , 04-Авг-25, (42) +1

А много их у тех, кто грызет гранит науки Вот когда вы попробуете погрызть г, Аноним (20), 12:37 , 04-Авг-25, (46)
У нас как у орков в вахе они сами растут Поэтому и топим за С, Weders (ok), 13:03 , 04-Авг-25, (53) +1

ну как показать вам код, который под NDA Хотя тут надо отвечать вопросом на воп, Аноним (20), 12:25 , 04-Авг-25, (41) +1

Так проблема в том, что каждый сишник ошибается немного в другом месте А резуль, Аноним (-), 12:36 , 04-Авг-25, (45)

Результат некорректного алгоритма - очевиден, и ошибка с памятью это формально н, Аноним (20), 12:51 , 04-Авг-25, (49)

Точно Или может это проблема в конкретной реализации конкретного алгоритма Проб, Аноним (-), 13:05 , 04-Авг-25, (55) –1

А вы как формально описали память Выход за границу у вас также формально должен, Аноним (20), 13:50 , 04-Авг-25, (63)

Вот в том то и проблема Нет пряморуких сишников Вот просто нет и все Нет, име, Аноним (-), 14:10 , 04-Авг-25, (72)

Если сишник всю жизнь писал хелловроты он пряморукий Так в чем проблема, в вашем, Аноним (20), 14:42 , 04-Авг-25, (87)

Нет, он просто еще не показал свою криворукость При том, что это в стандарте , Аноним (-), 15:12 , 04-Авг-25, (93) +1

И что написано ведь решай как знаешь решай как знаешь это и есть x его , Аноним (20), 15:44 , 04-Авг-25, (113)
Ахаха Бл Прям в Фонд золотых цитат сишников А нафига нужен такой стандарт, Аноним (-), 16:04 , 04-Авг-25, (127) +1
если потребитель это схавает, то допустимо Иначе он потребитель должен провер, Аноним (20), 16:23 , 04-Авг-25, (131)

Видишь ли, безрукие не проходят естественный отбор в силу того, что рукастые пол, Аноним (4), 13:10 , 04-Авг-25, (56)

Лишенные рук не лишены мозгов, и могут утереть нос многим двуруким, у них на то , Аноним (20), 13:57 , 04-Авг-25, (65)

А у девчуль больше мотивации заводить пары с двурукими, чем с безрукими В этом, Аноним (4), 15:21 , 04-Авг-25, (99)

А безруких девчуль природа уже отменила Это что-то из серии про девочки не пук, Аноним (20), 15:50 , 04-Авг-25, (117) –1

Он не просил показать код - он просил показать показать пряморуких сишников А т, Аноним (4), 13:04 , 04-Авг-25, (54) +1

я вайбкодер, я квадробер , Аноним (20), 13:59 , 04-Авг-25, (67)

Я не могу проверить, действительно ли сишный код под NDA так хорош, так что для , Fracta1L (ok), 15:22 , 04-Авг-25, (100)

ну а мне как проверить, действительно ли прямые руки у программиста , Аноним (20), 15:52 , 04-Авг-25, (119)

Твоё мнение насчёт прямоты рук не имеет практического смысла, факт в том, что пр, Fracta1L (ok), 15:56 , 04-Авг-25, (122) +1

Ну избавились мы от этого и получили что Раст Какое средство языка си мешает и, Аноним (20), 16:31 , 04-Авг-25, (134)

Ага, язык нового поколения, который пытается исправить недостатки предыдущего Ни, Аноним (-), 16:43 , 04-Авг-25, (137)

я просто не понимаю, зачем вы их называете программистами это ведь криворукие , Аноним (20), 16:53 , 04-Авг-25, (141)

А потому что других нет В стране одноглазых двуглазый не будет нормой Так вот, , Аноним (-), 16:56 , 04-Авг-25, (143)

дураком быть не запретишь, в мире раста я так думаю дураков не существует , Аноним (20), 16:58 , 04-Авг-25, (145)
Конечно существуют Тут вопрос в финальном результате Если компилятор надавал по, Аноним (-), 17:02 , 04-Авг-25, (146)
а всего то надо было просто греть в горне гвозди, а потом их забивать молотом, и, Аноним (20), 20:29 , 04-Авг-25, (182)

Я же объяснил логику выше, если ты не понимаешь, почему ну пусть просто все пиш, Fracta1L (ok), 16:43 , 04-Авг-25, (138) +1

вот именно, что нигде не написано как надо , и каждый компилятор по своему это , Аноним (20), 16:56 , 04-Авг-25, (144) –1

Вам бы с логикой-то подружиться Стандарт говорит делай что хочешь , компилятор, Аноним (4), 17:51 , 04-Авг-25, (156)

и судя по вашей логике надо стандарт менять Идите пишите свой компилятор, н, Аноним (20), 20:37 , 04-Авг-25, (187)

Так как мы уже от проблемы избавились и получили Раст, то и вопрос как избавить, Аноним (4), 17:46 , 04-Авг-25, (155)

Эх, сколько телодвижений для исправления того, что ущербно с даты создания Зато , Фнон (-), 11:31 , 04-Авг-25, (23) –4

достаточно взять ржавый и начать писать extern C потому что без сишного ABI он, Аноникл (?), 11:47 , 04-Авг-25, (29) +3

Плюсы без extern C тоже мало кому нужны Но это как раз стиму выбросить сишку о, Аноним (-), 12:28 , 04-Авг-25, (43)

Это просто невозможно, у Rust нет собственного ABI, зато например есть у Go , Аноним (35), 13:32 , 04-Авг-25, (60)

https doc rust-lang org reference items external-blocks htmlThe following ABI , Аноним (47), 15:13 , 04-Авг-25, (94)
Ты не поверишь, но у Сишочки его тоже нет, ибо оно специфично для платформы Есл, Аноним (4), 15:25 , 04-Авг-25, (103)

Ты просто бьешь ниже пояса Или ты надеялся, что хотя бы половина местных 12931, Аноним (-), 15:30 , 04-Авг-25, (107)

и просто выбросить , Аноним (51), 12:58 , 04-Авг-25, (52)

Режим, при котором для компиляции программы нужно будет проходить KYC шутка , Аноним (74), 14:15 , 04-Авг-25, (74) +1
Си - сила Лучший язык программирования И не стоит на месте, а развивается, не , xsignal (ok), 14:18 , 04-Авг-25, (76) +1

Рептилоиды придумали раст, чтобы подсадить на него человечество извести сишников, Аноним (101), 15:31 , 04-Авг-25, (109)

Да, подсадная утка, 100 , xsignal (ok), 15:40 , 04-Авг-25, (111)

Скрыто модератором, Аноним (-), 15:49 , 04-Авг-25, (116) –1

Скрыто модератором, xsignal (ok), 15:57 , 04-Авг-25, (123) –1

Скрыто модератором, Аноним (-), 16:09 , 04-Авг-25, (128)

Скрыто модератором, xsignal (ok), 16:27 , 04-Авг-25, (133)
Скрыто модератором, xsignal (ok), 16:37 , 04-Авг-25, (135)

Скрыто модератором, Аноним (-), 16:54 , 04-Авг-25, (142) +1

Скрыто модератором, xsignal (ok), 17:03 , 04-Авг-25, (147)
Скрыто модератором, xsignal (ok), 17:43 , 04-Авг-25, (154)

Скрыто модератором, 12yoexpert (ok), 20:27 , 04-Авг-25, (181)

Назрел такой вопрос проблема в программистах или на С С просто невозможно пис, Аноним (78), 14:19 , 04-Авг-25, (78)

Ни на каком языке невозможно писать безопасный код - это архитектурный изъян чел, xsignal (ok), 14:24 , 04-Авг-25, (79) +2

Извини, дружок, но более 70 уязвимостей как раз таки от ошибок при работе с пам, Аноним (4), 18:02 , 04-Авг-25, (159) +1

Скрыто модератором, xsignal (ok), 18:07 , 04-Авг-25, (160) –1

Скрыто модератором, Аноним (-), 18:25 , 04-Авг-25, (163) +1

Скрыто модератором, xsignal (ok), 19:11 , 04-Авг-25, (166)

Скрыто модератором, Аноним (-), 19:31 , 04-Авг-25, (168)

В случае с С С это человеческий фактор, так как компилятор ни о чём не предупр, Rev (ok), 14:28 , 04-Авг-25, (82)

То есть, технически возможно писать безопасный код на С С Все верно , Аноним (78), 14:52 , 04-Авг-25, (90) –1

Технически, можно переделать стиральную машину или холодильник в космический кор, Аноним (47), 15:34 , 04-Авг-25, (110) –1

Стиральную машину или холодильник в подводную лодку нельзя Толщина металла не п, Аноним (51), 19:37 , 04-Авг-25, (170)

Бензопила это безопасный инструмент Допустим что да, тогда отбиться ей от нашест, Аноним (101), 15:41 , 04-Авг-25, (112) +1

То что возможно сломать будет сломано, анонимус (??), 14:28 , 04-Авг-25, (83) –1
Нет такого языка Есть Си, а есть С на котором можно писать как на си, но не , Аноним (-), 14:38 , 04-Авг-25, (85) –2

Прямо указал что языки, а не язык , Аноним (78), 14:51 , 04-Авг-25, (89)
с каких пор программирование это рутина вы каждый раз заново пишите, допустим а, Аноним (20), 14:53 , 04-Авг-25, (91)

А где там написано что программирование это рутина Там написано про рутинные д, Аноним (-), 15:20 , 04-Авг-25, (98)

Я вспомнил об этом 10 лет назад, когда в одной отечественной cms неправильно пис, Аноним (86), 15:46 , 04-Авг-25, (114)

А в чем ошибка-то Опечатка в имени функции никак не влияет на то, во что эта фун, Аноним (-), 15:55 , 04-Авг-25, (121)

include stdio h рутина include stdio h - ерунда зачем тратить на это врем, Аноним (20), 16:41 , 04-Авг-25, (136)

Отлично Ок, допустим внимательности Х - const, и за 3 дня человек допускает Y ош, Аноним (101), 15:48 , 04-Авг-25, (115)

Именно Вот только это про раст, а не про си Ты накосячил - компилятор просто не, Аноним (-), 15:53 , 04-Авг-25, (120)

Я без предъяв, но вы не рассматриваете вариант, что тратя внимательность на ерун, Аноним (86), 15:57 , 04-Авг-25, (124)

Возможно Но ты ее точно также развиваешь, тратя не на ерунду И этой неерунды ты, Аноним (-), 16:13 , 04-Авг-25, (130)

На такой вопрос тебе никто не сможет ответь на 100 Всегда найдется умник с зач, Аноним (-), 14:47 , 04-Авг-25, (88)

У любого языка, который много лет используется для написания тонн кода, вскроютс, xsignal (ok), 15:09 , 04-Авг-25, (92)

И какие проблемы, с таким импактом CVE RCE есть у джавы или шишарпа Или может у , Аноним (-), 15:14 , 04-Авг-25, (95)

Всё есть, логические ошибки есть везде В том, что ошибки обнаруживаются, нет нич, xsignal (ok), 15:29 , 04-Авг-25, (105)
Имеете ввиду тот, кто из года в год придумывает всё новые безопасные языки, ко, Аноним (86), 15:51 , 04-Авг-25, (118) +1
Криворукость сишников никто не отменял, но из этого не может следовать, что на с, Аноним (20), 16:10 , 04-Авг-25, (129) –1

Много работал с C C в начале-середине 2000-х, но в некоммерческом применении , Аноним (86), 15:30 , 04-Авг-25, (108)

Ну не хочу обидеть, но некоммерческом применение это немного Но такой код пол, Аноним (-), 16:02 , 04-Авг-25, (126)

Никаких обид Для того и написал, чтобы читающий мой ответ, понимал, какого ур, Аноним (86), 17:05 , 04-Авг-25, (148)

129309 У меня просто 15 лет комерческой разработки и там все бывает очень ж, Аноним (-), 18:09 , 04-Авг-25, (162)

Скрыто модератором, Аноним (151), 17:16 , 04-Авг-25, (151) –1
язык C C для программистов, раст - для веб-синьоровплюсы учат по книгам, раст , 12yoexpert (ok), 19:50 , 04-Авг-25, (175)

И как обычно gcc сделан для людей, а clang - для корпоративных винтиков И вот т, Аноним (-), 16:51 , 04-Авг-25, (140)

А вдруг ошибешься в паре слов и Армия Тьмы вырвется на свободу , Oldi (?), 19:41 , 04-Авг-25, (172)

Линус бы руки поотбивал, 12yoexpert (ok), 19:48 , 04-Авг-25, (173)
все быстренько включили опцию и побежали покупать новый цпу, 12yoexpert (ok), 19:49 , 04-Авг-25, (174)

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

1. "В Clang намерены добавить режим усиленной безопасности" –11 +/–

Сообщение от laindono (ok), 04-Авг-25, 10:32

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

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

4. "В Clang намерены добавить режим усиленной безопасности" –4 +/–

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

132. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (132), 04-Авг-25, 16:24

Его ошибка в том, что он не реализовал победу при Каннах, а не в потерях при переправе.

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

26. "В Clang намерены добавить режим усиленной безопасности" –6 +/–

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

96. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним на удаленке (-), 04-Авг-25, 15:17

Подтверждаю. Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода. Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99 в зависимости от категории надежности ПО. На плюсах доказать что код работает так как положено очень тяжело. Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием(по требованиям низкого уровня), тестированием по требованиям высокого уровня, тестированием  по требованиям комплексным и системным. Ну и пилоты испытатели в конце концов все тестируют на страх и риск. Ну и соответственно самые высокоуровневые тесты не всегда автоматизированы иногда они как протокол ручных манипуляций по приборной панели выполняются. А на уровне модульном и по аысокоуровневым требованиям конечно почти полная автоматизация со сбором покрытия и объяснением почему какое то покрытие не 100%. Пповеряетс как говорится любая операция в коде и последовательность выполнения тоже :). Это дорого и медленно, но вот в авиации лучше пока не придумали.Самолеты от этого не падают каждый раз кстати.  Ну и конечно у нас embedded software а не ваши Intel Xeon с терабайтом ОЗУ. У нас ПЗУ то в десятках мегабайт измеряется на приборах часто а уж ОЗУ и подавно в десятках или сотнях КБ.

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

150. "В Clang намерены добавить режим усиленной безопасности" +3 +/–

Сообщение от Аноним (4), 04-Авг-25, 17:10

> Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода
> Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99
Я сильно сомневаюсь, что бы работаете в гражданской авиации, ибо там десятилетиями используется Ада.
https://ak-12.livejournal.com/60382.html
> Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием
Нет, дружок, доказательство, что все работает достигается в первую очередь формальной верификацией, а потом уже идут аудиты безопасности. Потому что модульные тесты, написанные ручками и уж тем более само ручное тестирование не является доказательством чего-то.
> Ну и пилоты испытатели в конце концов все тестируют на страх и риск.
Вот тут я уже заржал в голос. В авиации он работает, господи.
> Это дорого и медленно, но вот в авиации лучше пока не придумали
Уважаемый эксперт погуглит, когда Аду изобрели и когда внедрили, в частности, в область гражданской авиации?
Я в принципе могу поверить, что у вас там какая-то особенная авиация, но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет. Ибо это как минимум отсутствие злравого смысла, а в целом - верх халатности.

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

183. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от aname (?), 04-Авг-25, 20:31

Ну, т.е. проверенно безопасный язык существует езё

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

185. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от aname (?), 04-Авг-25, 20:32

Ну, т.е. проверенно безопасный язык существует уже десятилетия и работает. Т.е. раст нинужен от совсем нинужен

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

70. "В Clang намерены добавить режим усиленной безопасности" –2 +/–

Сообщение от laindono (ok), 04-Авг-25, 14:06

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

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

73. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от АнонимЪ (?), 04-Авг-25, 14:11

Контрпример: doas.

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

97. "В Clang намерены добавить режим усиленной безопасности" –2 +/–

Сообщение от laindono (ok), 04-Авг-25, 15:19

command not found: doas

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

169. Скрыто модератором +/–

Сообщение от Аноним (-), 04-Авг-25, 19:36

>  Контрпример: doas.
Простите, бсд это маргинальщина даже для сего форума.
Если бы не было хурда, то я бы сказал "эталонное нинужна".

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

102. "В Clang намерены добавить режим усиленной безопасности" +/–

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

186. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от aname (?), 04-Авг-25, 20:35

Зачем ты пишешь дыряшечный код, а ответственность перекладываешь на других?

Ответить | Правка | Наверх | 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ообщить модератору

184. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от 12yoexpert (ok), 04-Авг-25, 20:32

упоминать в одном предложении си и бекенд/фронтент - кричать о своём диагнозе "веб-синьор"

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

2. "В Clang намерены добавить режим усиленной безопасности" +2 +/–

Сообщение от Аноним (-), 04-Авг-25, 10:33

> Реализуемые методы защиты часто приводят к отдельным несовместимостям с существующим кодом или нарушению ABI, что не позволяет активировать их по умолчанию.
Таких программ единицы. В Gentoo возможно для них прописать отдельные опции сборки в /etc/portage
Ставим безопасные опции сборки и пересобираем мир.
А rust не нужен.

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

3. "В Clang намерены добавить режим усиленной безопасности" +3 +/–

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

Сообщение от Аноним (-), 04-Авг-25, 15:28

Ты все делаешь так)
Просто ты не учитываешь годы, потраченные на изучение этих команд и прдолинг с консолькой.
Для нормального юзера файл шарится чегез гугл-драйв в тот же 1 клик.
Но рассказы про УМВР - это классика красноглазых форумов.
Если у вас все работает, то чего появляются темы "Как избавиться от щелчков при запуске приложений на системах с чипами Intel" ?
А проблемы с дровами? А с софтом?

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

188. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от aname (?), 04-Авг-25, 20:37

Текстовый вархаммер?

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

59. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (59), 04-Авг-25, 13:25

> А есть люди, которые ставят приложение в пару кликов. Представляете?
Одно приложение? Даже и в пару кликов!!!
Эти, даже представить себе не могут, что гентушник, всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.
А Я ОДНИМ нажатием на Enter, могу создать всю систему с нуля, пересобрать мир правильно и создать с него LiveDVD.
И с этого LivDVD могу ОДНИМ нажатием на Enter установить готовую собранную систему.

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

62. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Аноним (62), 04-Авг-25, 13:43

Никому, кроме тебя, не нужную?

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

139. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 16:51

Это ржавый не нужен, а моя система нужна всем: https://www.opennet.me/openforum/vsluhforumID3/137467.html#294

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

171. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 19:37

> Это ржавый не нужен, а моя система нужна всем
Твоя система нужна полторым землекопам.
А раст используют большая часть топовых фирм - именно те, кто развивают IT.
Ну а рассуждение про "заговор против СПО"... оставь такой шизоидный бред дря РЕНТВ.

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

75. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 14:17

> Эти, даже представить себе не могут, что гентушник,
> всего ОДНИМ нажатием на клавишу Enter может пересобрать весь мир.
Да, нужно только исправить все сломанное в portage.
А потом можно пойти попить чай на полдня или даже на день, смотря на каком унитазе он решил попомпилять.

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

176. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от ptr (ok), 04-Авг-25, 19:57

Ну с Rust ситуация еще хуже, так как нет стабильного ABI. Там для новой версии компилятора нужно перекомпилировать каждый раз вообще всё или, отказываясь от безопасности при работе с памятью, использовать C ABI.

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

178. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 20:13

> Ну с Rust ситуация еще хуже, так как нет стабильного ABI.
Разве у C есть какое-то ABI ?
Что-то в стандарте я такого не видел.
> Там для новой версии компилятора нужно перекомпилировать каждый раз вообще всё или, отказываясь от безопасности при работе с памятью, использовать C ABI.
C++ как-то с этим живет - у них примерно каждые 3 версии ломают.
И ничего, никто не умер, язык повсеместно используется и для прикладного ПО и для ОС.

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

180. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от ptr (ok), 04-Авг-25, 20:26

> Разве у C есть какое-то ABI ?
Посмотрите внимательно на диск своего компьютера. Все dll/so в нем используют один и тот же стандартный для этой операционной системы С ABI.
Так же поступает и Rust при спецификации extern "C".
Если бы это было иначе, то ни о каком динамическом связывании вообще речи быть не могло. Прикладная программа даже к операционной системе не смогла бы обратиться.
> C++ как-то с этим живет
Во-первых, C++ поддерживает C ABI. Так же как и Rust. И с теми же ограничениями и проблемами с безопасностью, что в этом смысле уравнивает C++ и Rust.
Во-вторых, Clang и GCC уже давно поддерживают Itanium C++ ABI. Альтернативные расширенные варианты предлагают некоторые фреймворки, как, например, Qt.

Ответить | Правка | Наверх | 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 намерены добавить режим усиленной безопасности" –4 +/–

Сообщение от Аноним (10), 04-Авг-25, 11:00

Раст или так же роняет производительность либо имеет под собой худшую защиту.

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

13. "В Clang намерены добавить режим усиленной безопасности" +6 +/–

Сообщение от Аноним (-), 04-Авг-25, 11:17

> Раст или так же роняет производительность либо имеет под собой худшую защиту.
Нет. В расте за лучшую защиты ты платишь размером временных файлов и временем компиляции во время которого проводятся все проверки - анализ лайфтаймов, владение, типизация и так далее.
Вот только программа компилится только один раз, а запускается на порядки больше раз (за исключением гентушников-ноулаферов, которым только дай покомпилять).
А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.
Но диды продолжаю ныть "раст не влазит на мой HDD 40GB", "лиса компилируется долго", "это нужно целую билдферму делать".

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

21. "В Clang намерены добавить режим усиленной безопасности" –5 +/–

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

Сообщение от Аноним (-), 04-Авг-25, 15:29

> И в чём они неправы?
В том, что для каждого времени и для каждого инструмента есть свои требования.
HDD 40GB должны остаться где-то... во временах Maxtor, если вы еще помните такую фирму))
Новый инструмент дает новые гарантии, но и просит "оплатить" это требованиями к железу.
Если ваше железо не соответствует - это ваша проблема.
Вы же не возмущаетесь что современное авто невозможно нормально отремонтировать в гараже?
Вот тут аналогичная ситуация.

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

161. "В Clang намерены добавить режим усиленной безопасности" –2 +/–

Сообщение от Аноним (-), 04-Авг-25, 18:08

> А рантайм проверки роняют производительность каждому юзеру и для каждого запуска.
Ещё раз. Гарантии безопасности в C, C++ даются при исполнении программы. И от ржавого требуется в принципе тоже. При компиляции некие проверки есть. При запуске проверок частных нет, есть связывание всех библиотек. При работе есть постоянные проверки памяти - проактивная защита. И эти постоянные проверки работы с памятью в правильных ядрах OS на правильных CPU не влияют на производительность!

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

164. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (164), 04-Авг-25, 18:38

> И эти постоянные проверки работы с памятью в правильных ядрах OS на правильных CPU не влияют на производительность!
О как! Правильные ОС и ядра у нас поди на чистой магии работают?

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

167. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 19:20

Не на магии, а на спец инструкция процессоров и действительно ядра OS могут отлавливать переполнение буфера постранично без накладных расходов: https://www.opennet.me/openforum/vsluhforumID3/137467.html#304

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

177. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от ptr (ok), 04-Авг-25, 20:13

Цена этого - или многократное дублирование кода при статическом связывании, или использование C ABI для динамического связывания, вообще отказавшись от подобных проверок.
И когда хост k8s начитает из-за Rust требовать в разы больше оперативной памяти даже по сравнению с .NET или Java, это уже, обычно, не о 40ГБ речь, а сотнях гигабайт оперативки.

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

179. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 20:20

> Цена этого - или многократное дублирование кода при статическом связывании, или использование C ABI для динамического связывания, вообще отказавшись от подобных проверок.
Но все внутренние проверки и гарантии останутся.
Т.е будет какое-то unsafe связывание, а дальше стандартные проверки.
> И когда хост k8s начитает из-за Rust требовать в разы больше оперативной памяти даже по сравнению с .NET или Java, это уже, обычно, не о 40ГБ речь, а сотнях гигабайт оперативки.
Ну... не все занимаются контейнерами.
Для локальных приложений это вообще не важно.

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

15. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от выф (?), 04-Авг-25, 11:19

А можно чуть раскрыть тему для нубов в расте?
Растоводы кричат что всё пучком.

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

16. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (4), 04-Авг-25, 11:22

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

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

47. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (47), 04-Авг-25, 12:43

> А можно чуть раскрыть тему для нубов в расте?
> Растоводы кричат что всё пучком.
Ну, обычная методичка местных военов против раста.
Типа "жирные бинари", "жирный, обязательный рантайм" и прочего.
У них даже получалось хелловорлды на расте собирать чуть ли не на десяток МБ, что конечно же служит самым веским доказательством их̵ ̵к̵р̵и̵в̵ы̵х̵ ̵р̵у̵к̵ их тезисов.
А когда кто-то из мерзких растаманов тыкнет их носом в минимальный хелловрот меньше 1КБ и предложит поискать там рантайм и "жир", можно заявить, что это враки и несчитается и вообще, на си/асме можно еще меньше написать (правда, демонстрировать это военам некогда, им дальше супротив раста воевать надо).

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

51. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (51), 04-Авг-25, 12:56

> Растоводы кричат что всё пучком.
Просто нет на них Дмитрия Пучкова.

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

152. "В Clang намерены добавить режим усиленной безопасности" –2 +/–

Сообщение от Аноним (-), 04-Авг-25, 17:19

https://www.opennet.me/openforum/vsluhforumID3/137467.html#310 после этого поста через один было разъяснение, мордеры удалили.
Раст не может дать гарантии безопасности, стабильности при исполнении и не имеет верифицируемость кода.
C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS) в ущерб гарантиям стабильности в виду отсутствия формальной математической верификации кода.

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

153. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 17:36

> Раст не может дать гарантии безопасности, стабильности при исполнении и не имеет
> верифицируемость кода.
Громкое заявление.
А как же гарантии и проверки на этапе компиляции?
Которые проверят, что при исполнении не нарушится ownership и лайфтаймы.
> C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS) в ущерб гарантиям стабильности в виду отсутствия формальной математической верификации кода.
Т.е они вообще без средств ОС не дают никаких гарантий?
Звучит весьма буллщитно.

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

157. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (-), 04-Авг-25, 17:53

В C, C++ гарантии безопасности не даются только одним компилятором. Хотя сегодня компиляторы C, C++ делают очень много для получения безопасного и стабильного бинаря.
В C, C++ гарантии безопасности даются всей системой в целом и в ущерб гарантиям стабильности: https://www.opennet.me/openforum/vsluhforumID3/137467.html#58
Ржавый не даёт общих гарантий безопасности во время исполнения, частные случаи. Проверки во время компиляции могут в некой степени уменьшать или ликвидировать некие популярные дыры, как и в C, C++. Гарантий стабильности ржавый также не даёт. Верифицируемости кода ржавый не имеет. В целом мое мнение о переписывании кода на ржавом кем-то задумано, как заговор с целью притормозить развитие СПО. Напоминает переписывания с питон 2 на 3 которое на пару лет притормозило динамичное развитие питона.

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

158. "В Clang намерены добавить режим усиленной безопасности" +2 +/–

Сообщение от Аноним (4), 04-Авг-25, 17:56

> Раст не может дать гарантии безопасности
> C, C++ может дать гарантии безопасности при исполнении (проактивная защита CPU и ядро OS)
То есть "проактивная защита CPU и ядро OS" гарантированно защищают программы, написанные на C и C++, но не защищают написанные на Расте. Я все правильно понял?

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

165. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (-), 04-Авг-25, 18:54

Проактивная защита CPU + ядро OS дадут гарантии безопасности и корректности работы с памятью сразу для всех программ на всех языках программирования, включая ржавого. Но за это придется заплатить отсутствием гарантий стабильности при использовании проективной защиты.
Если C, C++ прога имеет дыру и кто-то напишет экспорт, то при запуске этого экспорта проактивная защита убьет процесс - отсутствие гарантий стабильности.
Если прога на ржавом, абсолютно корректно работает с памятью, дыр не имеет, эксплоитов не цепляет, то проактивная защита ее убивать не будет. Но в С дыр нашли много, там не только переполнение буфера. Все ли позатыкали в ржавом не знаю. Надо тестить ржавого с проективной защитой!
C, C++, Assembler, Foltran, Pascal (fpc) - с проективной защитой работают хорошо. Pascal имеет проверки памяти на этапе компиляции, но этого мало чтобы получить гарантии стабильности при проективной защите.

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

149. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 17:06

Флаги безопасности не сильно роняют производительность, там проценты, в парах есть. Флаги оптимизации поднимут производительность так, что общая выйдет в плюсе.
Есть пару пакетов с USE флагами: pic -asm которые вырежут пока плохо написанную асемблерную оптимизацию SIMD инструкциями. Вот для этих пару пакетов производительность может упасть заметно, надо иметь ввиду и тестировать:
app-arch/gzip
app-arch/lrzip-next
dev-libs/libsecp256k1
net-p2p/bitcoin-core

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

9. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Аноним (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. Скрыто модератором +2 +/–

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

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

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

141. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (20), 04-Авг-25, 16:53

> А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?
я просто не понимаю, зачем вы их называете программистами? это ведь "криворукие" погроммисты.
> Никакое.
не освобождать - религия запрещает?

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

143. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 16:56

>> А какое может быть решение если 40+ лет пограммисты делают изо дня в день одни и те же глупые ошибки?
> я просто не понимаю, зачем вы их называете программистами? это ведь "криворукие" погроммисты.
А потому что других нет)
В стране одноглазых двуглазый не будет нормой.
Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.

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

145. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (20), 04-Авг-25, 16:58

> Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.
дураком быть не запретишь, в мире раста я так думаю дураков не существует?

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

146. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 17:02

>> Так вот, "норма" для программиста на сишке - это делать ошибки по памяти.
> дураком быть не запретишь, в мире раста я так думаю дураков не существует?
Конечно существуют!
Тут вопрос в финальном результате.
Если компилятор надавал по рукам и заставил исправить, в итоге код валидный и нет уязвимостей... то меня это устроит на 100%.
Вам шашечки или ехать? (с)
Это нормально, когда инструмент становится не только лучше по качеству, но и защищает от человеческих ошибок.
Вся история Техники Безопасности как раз про это)

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

182. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (20), 04-Авг-25, 20:29

> Конечно существуют!
> Вся история Техники Безопасности как раз про это)
а всего то надо было просто греть в горне гвозди, а потом их забивать молотом, и по пальцем никогда не попадем, потому-что держать их будем вовсе не руками :)

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

138. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Fracta1L (ok), 04-Авг-25, 16:43

Я же объяснил логику выше, если ты не понимаешь, почему "ну пусть просто все пишут как надо" не работает, то я ничем помочь не могу.

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

144. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (20), 04-Авг-25, 16:56

> "ну пусть просто все пишут как надо"
вот именно, что нигде не написано "как надо", и каждый компилятор по своему это все может делать, на что и указывает стандарт.
> Я же объяснил логику выше
А я вам хочу донести лишь одно, все ваши претензии должны быть направлены на конкретный компилятор и на собственную криворукость, а не на язык и его стандарт.

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

156. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (4), 04-Авг-25, 17:51

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

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

187. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (20), 04-Авг-25, 20:37

> но виноваты в последствиях пресловутые "ненастоящие сишники
и судя по вашей логике надо стандарт менять? :) Идите пишите свой компилятор, "настоящий" вы наш, если вас существующие компиляторы не устраивают, а если дойдет дело до переписывания стандарта, то вы будете последний к кому прислушаются (ничего личного).
> И, главное, Раст не нужен - нужно просто стать настоящим сишником!
Не сишником надо быть, а "настоящим".
> Цирк да и только...
Ну конечно, ведь "Войну и мир" может написать, только владеющий русским языком.

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

155. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (4), 04-Авг-25, 17:46

> Ну избавились мы от этого и получили что? Раст? Какое средство языка си мешает избавлению от use-after-free?
Так как мы уже от проблемы избавились и получили Раст, то и вопрос "как избавиться от use-after-free в С" уже не актуален.

Ответить | Правка | К родителю #134 | Наверх | 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 намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Аноним (74), 04-Авг-25, 14:15

Режим, при котором для компиляции программы нужно будет проходить KYC (шутка).

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

76. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от xsignal (ok), 04-Авг-25, 14:18

Си - сила! Лучший язык программирования. И не стоит на месте, а развивается, не ломая совместимость при этом. А все нападки на Си - спланированная и оплаченная кампания по дескридитации с целью вытеснить независимых разработчиков из мира свободного ПО.

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

109. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (101), 04-Авг-25, 15:31

Рептилоиды придумали раст, чтобы подсадить на него человечество извести сишников, и больше никогда человечество не смогло вернуться к гнутым истокам как завещали наши великие предки.
> спланированная и оплаченная
Зачем дурачкам платить, дурачки за просто так будут в лепешку расшибаться чтобы доказать чтото.

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

111. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от xsignal (ok), 04-Авг-25, 15:40

> чтобы подсадить на него человечество извести сишников
Да, подсадная утка, 100%!

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

116. Скрыто модератором –1 +/–

Сообщение от Аноним (-), 04-Авг-25, 15:49

> И не стоит на месте, а развивается, не ломая совместимость при этом.
Аж жЫр с монитора потек.
> кампания по дескридитации
Никто не дискредитирует сишников так хорошо как сами сишники.
> оплаченная
Не правда! Я абсолютно без-воз-мезд-но, то есть даром (с) и с огромным удовольствием пишу про сишные дырени везде где можно. Ведь многие люди не знают про опасность, которую таит в себе 6ыdloкод не небезопасном йазычке из 70х! А потом они удивляются как их телегу ломают просто прислав "специально оформленное изображение".
Люди просто должны об этом знать, думать об этом, писать своему депутату "а вдруг в этом авто используется опасный код?!" и требовать запрета небезопасных языков.
И по последним изменениям видно, что эта деятельность дает свои плоды.

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

123. Скрыто модератором –1 +/–

Сообщение от xsignal (ok), 04-Авг-25, 15:57

> Никто не дискредитирует сишников так хорошо как сами сишники
Весь лучший базовый софт, за счёт которого ещё не рушится, не смотря на все старания некоторых, а прочно стоит огромное здание современного IT, написан на Си.

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

128. Скрыто модератором +/–

Сообщение от Аноним (-), 04-Авг-25, 16:09

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

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

133. Скрыто модератором +/–

Сообщение от xsignal (ok), 04-Авг-25, 16:27

> С чего начнем?
Да хотя бы Apache и nginx - несущие платформы всего сегодняшнего интернета! И с этим они более чем отлично справляются, и Си никак не мешает, если голова на плечах есть.

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

135. Скрыто модератором +/–

Сообщение от xsignal (ok), 04-Авг-25, 16:37

> Видна это с++ и даже раст
Ахаха) Ну с этим глюкодромом всё понятно, хороший антипример!)

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

142. Скрыто модератором +1 +/–

Сообщение от Аноним (-), 04-Авг-25, 16:54

>> Винда это с++ и даже раст
> Ахаха) Ну с этим глюкодромом всё понятно, хороший антипример!)
Про глюкодром это личный опыт)?
Неужели она более падучая чем плазма или более блевотная чем всякие крыски?
Удивительно, что такой классный линукс имеет 5% дестопа!
Но примеры великих СИшных программ ты так и не привел)
ps нгикс это та самая программ в которой
opennet.ru/opennews/art.shtml?num=61269
"... судя по исправлениям в коде уязвимости вызваны обращением к уже освобождённой памяти (use-after-free), неверным выделением памяти под массив, разыменованием нулевого указателя и отсутствием должной проверки размера помещаемых в буфер данных."
Т.е типичная СИшная дрыстня.

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

147. Скрыто модератором +/–

Сообщение от xsignal (ok), 04-Авг-25, 17:03

> ps нгикс это та самая программ в которой
> opennet.ru/opennews/art.shtml?num=61269
И что? WWW по всему миру из-за этого лёг?)

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

154. Скрыто модератором +/–

Сообщение от xsignal (ok), 04-Авг-25, 17:43

> Но примеры великих СИшных программ ты так и не привел)
А что, Apache и nginx - движков всея интернета тебе мало? Ну тогда git, например - система контроля версий, покорившая весь мир, что скажешь?

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

181. Скрыто модератором +/–

Сообщение от 12yoexpert (ok), 04-Авг-25, 20:27

> С ос? Видна это с++ и даже раст, макось - обжси.
ты путаешь магазины и ОС, смысл с тобой разговаривать

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

78. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (78), 04-Авг-25, 14:19

Назрел такой вопрос: проблема в программистах или на С/С++ просто невозможно писать безопасный код? Хочу научиться программировать и разрываюсь между С/С++ и Rust. Если проблема лишь в компетентности - выберу первые языки, но если это архитектурный изъян - второй.

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

79. "В Clang намерены добавить режим усиленной безопасности" +2 +/–

Сообщение от xsignal (ok), 04-Авг-25, 14:24

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

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

159. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Аноним (4), 04-Авг-25, 18:02

> Можно встроить в язык кучу костылей, которые снизят риск ошибок при работе с памятью, но это никак не поможет от совершения логических ошибок, которые приводят к уязвимостям.
Извини, дружок, но более 70% уязвимостей как раз таки от ошибок при работе с памятью, а не от логических.

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

160. Скрыто модератором –1 +/–

Сообщение от xsignal (ok), 04-Авг-25, 18:07

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

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

163. Скрыто модератором +1 +/–

Сообщение от Аноним (-), 04-Авг-25, 18:25

> Важно не количество, а последствия.
heartbleed, dirty COW, тысячи уязвимостей в либах типа glibc, libwebp и прочих с последствиями от denial-of-service до удаленного выполнения кода.
> Много уязвимостей при работе с памятью обнаруживаются - это хорошо, значит программы, написанные на Си, поддаются исследованию на предмет безопасности.
Ага, а потом читаешь новости "в XOrg нашли уязвимость 1988 года"))
Грязная корова жила я ядре с 2007 года до 2016.
Куда пырились все это время тысячи глаз - вопрос открытый.
Bashdoor/Shellshock целое семейство CVE - выявили в 2014, были созданы в 1992.
Heartbleed - всего-то 3 года - приятное исключение))
> А попробуй-ка найди уязвимости, которые наговнокодил какой-нибудь растовщик в состоянии расслабленного мозга...
Как говорится "делай хорошо - хорошо будет". Просто не пиши на ущербном недоязыке из прошлого века и не придется разбирать уязвимости.

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

166. Скрыто модератором +/–

Сообщение от xsignal (ok), 04-Авг-25, 19:11

> последствиями от denial-of-service до удаленного выполнения кода
Ну и? Какие последствия-то кроме эфемерных возможностей "удалённого выполнения кода"?
> "в XOrg нашли уязвимость 1988 года"
И сильно кому-то повредила эта уязвимость 88-го года?..
Все эти слова про теоретические уязвимости - пустота, за ними ничего реального не стоит, все масштабные сбои и взломы последних лет - чисто криворукость админов, хранивших пароли в файле passwords.txt, чем хакеры и пользовались.
> Просто не пиши на ущербном недоязыке из прошлого века
Просто не пользуйся круглыми колёсами прошлого века - катайся на треугольных - они дадут тебе совершить опасный манёвр на большой скорости и позаботятся о твоей безопасности!

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

168. Скрыто модератором +/–

Сообщение от Аноним (-), 04-Авг-25, 19:31

> Ну и? Какие последствия-то кроме эфемерных возможностей "удалённого выполнения кода"?
Каких эфемерных?
Вот типичная СИшная либа - libwebp
opennet.ru/opennews/art.shtml?num=59746
"критическая уязвимость вызвана переполнением буфера в обработчике формата изображений WebP. Уязвимость позволяет выполнить свой код при обработке специально оформленных WebP-изображений. Опасность уязвимости усугубляет то, что в сети выявлен рабочий эксплоит, который уже применяется злоумышленниками для совершения атак (0-day). "
> Все эти слова про теоретические уязвимости - пустота, за ними ничего реального не стоит, все масштабные сбои и взломы последних лет - чисто криворукость админов, хранивших пароли в файле passwords.txt, чем хакеры и пользовались.
Да что ты несешь! (с)
Не чувак, реально хватит порочу чушню.
Bashdoor - через него делали ботнеты,
Dirty COW - через нее ломали и линукс серваки (Ebury) и андроид телефоны.
Даже сайт kernel.org ломанули и бекдор жил два года.
opennet.ru/opennews/art.shtml?num=61186
Хватит куракекать про "теоретические уязвимости", просто не позорься.

> Просто не пользуйся круглыми колёсами прошлого века - катайся на треугольных - они дадут тебе совершить опасный манёвр на большой скорости и позаботятся о твоей безопасности!
Хе, твоя аналогия просто ущербна /_-
Давай сравним круглое деревянное колесо как на первых авто, с каучуковым покрытием.
И современное бескамерное с радиальным кордом и литым диском.
Ну так во СИшка, это каменное колесо)

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

82. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Rev (ok), 04-Авг-25, 14:28

В случае с С/С++ это человеческий фактор, так как компилятор ни о чём не предупреждает.
А в Rust компилятор все спорные ситуации покажет и откажется такой код компилировать.
Я, как ленивая жопа, предпочитаю писать на Расте, так как это требует меньше когнитивных напряжений.

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

90. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (78), 04-Авг-25, 14:52

То есть, технически возможно писать безопасный код на С/С++? Все верно?

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

110. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (47), 04-Авг-25, 15:34

> То есть, технически возможно писать безопасный код на С/С++? Все верно?
Технически, можно переделать стиральную машину или холодильник в космический корабль или подводную лодку, все верно.

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

170. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (51), 04-Авг-25, 19:37

Стиральную машину или холодильник в подводную лодку нельзя. Толщина металла не позволит выдержать внешнее давление.

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

112. "В Clang намерены добавить режим усиленной безопасности" +1 +/–

Сообщение от Аноним (101), 04-Авг-25, 15:41

Бензопила это безопасный инструмент?
Допустим что да, тогда отбиться ей от нашествия зомби нельзя, а значит она не нужна
Допустим что нет, и маньяк может запилить десяток человек забежав на детский утренник, а значит она не нужна.
Пользуйтесь пилкой для ногтей
От зомби не поможет никак, но можно засадить комуто в глаз..но так их сейчас из пенопласта делают, абсолютно безопасная, но можно ее порезать и устроить так чтобы ктото задохнулся..но задушить можно и руками, черт. абсолютно безопасно только то чего не существует, но идеи убивают похлеще всяких оружий...то есть технически..ну вы поняли

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

83. "В Clang намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от анонимус (??), 04-Авг-25, 14:28

То что возможно сломать будет сломано

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

85. "В Clang намерены добавить режим усиленной безопасности" –2 +/–

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

Сообщение от Аноним (86), 04-Авг-25, 15:57

> лучше тратить внимательность на логику, а не на ерунду.
Я без предъяв, но вы не рассматриваете вариант, что тратя внимательность на ерунду я эту самую внимательность развиваю?

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

130. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 16:13

> тратя внимательность на ерунду я эту самую внимательность развиваю?
Возможно. Но ты ее точно также развиваешь, тратя не на ерунду.
И этой неерунды ты сможешь сделать намного больше до первой ошибки.
Плюс там есть гарантии, что за тебя проверят и сообщат "если что".

Ответить | Правка | Наверх | 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ообщить модератору

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 намерены добавить режим усиленной безопасности" –1 +/–

Сообщение от Аноним (20), 04-Авг-25, 16:10

> А что делает тот, кто совершает одни и те же ошибки из года в год?
> Знаешь, что такое безумие? (с)
Криворукость сишников никто не отменял, но из этого не может следовать, что на си нельзя писать корректные "прямые" программы. По безумцам в обществе нельзя судить о пандемии, она должна носить тотальный характер.

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

108. "В Clang намерены добавить режим усиленной безопасности" +/–

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

148. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (86), 04-Авг-25, 17:05

> Ну... не хочу обидеть, но некоммерческом применение это немного
Никаких обид :) Для того и написал, чтобы читающий мой ответ, понимал, какого уровня человек ему отвечает. В коммерческой разработке условия совсем другие, все эти сроки, гарантии, копания в чужом коде и т.д.
> А как же портируемость)?
В то время в этом и заключалась портируемость. a+b гарантированно сложит два числа на любом процессоре с минимумом накладных расходов, а вот мелочи уже будут на совести процессора. То же и с разрядностью типов типа int, который просто "не менее 16 бит", а сколько конкретно - непонятно.
> Звучит как разговоры старых водил, что с автоматом все разучатся водить)
Ага. Но по сути так и получается. Случись чего - многие полезут под капот? Меньшая самостоятельность, большая зависимость от других людей. А тем только этого и надо - опа и вот уже запчасти за 300% стоимости.
> В С++ АБИ частично ломается примерно каждые 3 версии.
А вот этого не знал, спасибо за информацию. Последний раз слышал о чём-то типа добавления поля count в списки, что ломало совместимость из-за изменения размеров объектов. Но я думал, что это разовое событие исключительной редкости.
> Форсируется - это как?
Про "нанимают раст-программистов" не скажу, но наверное да. Но суть в том, что очень много чего сейчас пишется на расте. Периодически в новостях вылезает из самых неожиданных мест. Имхо пока это хайп, как с ии или блокчейном. Но во что оно выльется, предсказать сложно. Сдуется, или ограничится какой-то нишей, или реально заменит C/C++.
> А можно такой пример?
Нет, я же не знаю раст :) Но в разных других местах, когда вводится что-то "для безопасности", оно часто бьёт и по нормальному использованию. Тот же ркн, блокирующий опасные сайты, блокирует и кучу нормальных сайтов... причём, больше нормальных чем опасных.
> > Но от выстрела в ногу он не защитит.
> Серьезное заявление, требующее доказательств.
Я имел ввиду, что от каких-то типов ошибок оно не защитит, и программист всё равно должен понимать, что он делает.

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

162. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 18:09

> Никаких обид :)
🤝
У меня просто 15 лет комерческой разработки... и там все бывает очень жестко.
>> А как же портируемость)?
> В то время в этом и заключалась портируемость. a+b гарантированно сложит два  числа на любом процессоре с минимумом накладных расходов, а вот мелочи уже будут на совести процессора.
Типа "я сказал ему сложить 2 числа, а вот какой результат, это не я несу ответственность".
Я бы называл это "портируемость" в кавычках.
> Ага. Но по сути так и получается. Случись чего - многие полезут под капот?
А зачем? Может я хочу купить надежное авто, к которому я не хочу лазить под капот?
Например - раньше надо было настраивать зазоры клапанов каждые 5тыщ пробега.
Занятие малоприятное, но тк ничего кроме жигулей не было - деваться некуда.
А потом появились гидрокомпенсаторы.
"А что так можно было?!" (с)
> Меньшая самостоятельность, большая зависимость от других людей.
Цивилизация началась с разделения труда.
Я не пеку хлеб, не ремонтирую авто. Лечить зубы я тоже пойду к профи.
Раньше можно было спаять из ворованных деталей Радио86, а сейчас даже ноут починить без bga пайки не выйдет.
Но мне что-то не хочется возвращаться в те времена)))
> А тем только этого и надо - опа и вот уже запчасти за 300% стоимости.
Наверное что-то случилось)
>> В С++ АБИ частично ломается примерно каждые 3 версии.
> Но я думал, что это разовое событие исключительной редкости.
К счастью нет. Тк язык должен развиваться.
Но никто не запрещает писать на условном rust 2018 или с89 долгие годы.
Ядро перешло с 89 на с11 только в 2022, ЕМНИП.
> Про "нанимают раст-программистов" не скажу, но наверное да. Но суть в том, что очень много чего сейчас пишется на расте. Периодически в новостях вылезает из самых неожиданных мест. Имхо пока это хайп, как с ии или блокчейном.
Ну, по первому пункту - это бизнес, если они видят, что разработка на расте может быть выгоднее - они его пробуют.
Хайпа я тут не особо вижу, рекламы по ТВ и интернете нету (как java - youtube.com/watch?v=SRLU1bJSLVg)
То что гугл в своем блоге что-то пишет, ну мало кто его читает.
> Сдуется, или ограничится какой-то нишей, или реально заменит C/C++.
Уже заменяет.
В андроиде 13 было 1.5 млн. строк код. В 16 версии еще больше.
Крупный бизнес cloudflare, microsoft, AWS пишет открытый код на нем.
Вольво внедряет в машины, китайцы в смарт часы и спутники.
> Нет, я же не знаю раст :)
> Но в разных других местах, когда вводится что-то "для безопасности", оно часто бьёт и по нормальному использованию.
Тогда, если вы не против, я поясню.
Одна из основных фич раста - проверка на этапе компиляции. Это имеет некоторые трейдоффы: компиляция может быть дольше, дебажный билд может быть существенно больше.
Но то что скомпилировалось 1 раз, у тысяч пользователей будет работать быстро.
По бенчмаркам выходит отставание на 1-2% в некоторых алгоритмах и одинаковая производительность в других.
> Тот же ркн, блокирующий опасные сайты, блокирует и кучу нормальных сайтов... причём, больше нормальных чем опасных.
Я бы не критиковал РКН на этом сайте, если вы не сидите через ТОР.
> Я имел ввиду, что от каких-то типов ошибок оно не защитит, и программист всё равно должен понимать, что он делает.
Естественно. Он должен понимать логику и алгоритмы.
Но если мы избавимся от целого пласта проблем с памятью, то можем уделять внимание логике.
Я выше привел ссылку на CVE ядра. Memory проблемы это топ с огромным отрывом.

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

151. Скрыто модератором –1 +/–

Сообщение от Аноним (151), 04-Авг-25, 17:16

Программист на Rust без знаний С и С++ никому не нужен.

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

175. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от 12yoexpert (ok), 04-Авг-25, 19:50

язык C/C++ для программистов, раст - для веб-синьоров
плюсы учат по книгам, раст по туториалам. делай выводы

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

140. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Аноним (-), 04-Авг-25, 16:51

> для усиления защиты по аналогии с добавленным в GCC 14 флагом "-fhardened"
И как обычно gcc сделан для людей, а clang - для корпоративных винтиков. И вот тут это все на отличненько вылезает.
Что вам лениво чтоли заучить заклинания вида "-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" ? :)

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

172. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от Oldi (?), 04-Авг-25, 19:41

А вдруг ошибешься в паре слов и Армия Тьмы вырвется на свободу ?

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

173. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от 12yoexpert (ok), 04-Авг-25, 19:48

Линус бы руки поотбивал

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

174. "В Clang намерены добавить режим усиленной безопасности" +/–

Сообщение от 12yoexpert (ok), 04-Авг-25, 19:49

все быстренько включили опцию и побежали покупать новый цпу

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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


	150. "В Clang намерены добавить режим усиленной безопасности"	+3 +/–
	Сообщение от Аноним (4), 04-Авг-25, 17:10
	> Работаю в гражданской авиации где есть авиационные стандарты на верификацию и тестирования кода > Используются компиляторы обычно старенькие и все почти полностью на чистом Си со стандартом ANSI, С89, С99 Я сильно сомневаюсь, что бы работаете в гражданской авиации, ибо там десятилетиями используется Ада. https://ak-12.livejournal.com/60382.html > Так вот доказательство что все работает как надо по разработанным требованиям к ПО (а это обязательна часть при разработке) достигается модульным тестированием Нет, дружок, доказательство, что все работает достигается в первую очередь формальной верификацией, а потом уже идут аудиты безопасности. Потому что модульные тесты, написанные ручками и уж тем более само ручное тестирование не является доказательством чего-то. > Ну и пилоты испытатели в конце концов все тестируют на страх и риск. Вот тут я уже заржал в голос. В авиации он работает, господи. > Это дорого и медленно, но вот в авиации лучше пока не придумали Уважаемый эксперт погуглит, когда Аду изобрели и когда внедрили, в частности, в область гражданской авиации? Я в принципе могу поверить, что у вас там какая-то особенная авиация, но вот в целом по миру заредкими исключениями никто критический по безопасности софт на Си не писал и не пишет. Ибо это как минимум отсутствие злравого смысла, а в целом - верх халатности.
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


	97. "В Clang намерены добавить режим усиленной безопасности"	–2 +/–
	Сообщение от laindono (ok), 04-Авг-25, 15:19
	command not found: doas
	Ответить \| Правка \| Наверх \| Cообщить модератору


	169. Скрыто модератором	+/–
	Сообщение от Аноним (-), 04-Авг-25, 19:36
	> Контрпример: doas. Простите, бсд это маргинальщина даже для сего форума. Если бы не было хурда, то я бы сказал "эталонное нинужна".
	Ответить \| Правка \| К родителю #73 \| Наверх \| Cообщить модератору


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


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


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

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


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


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