Фонд OSTIF (Open Source Technology Improvement Fund), созданный с целью усиления защищённости открытых проектов, объявил о завершении независимого аудита кода проекта LLVM. Работа выполнена английской компанией Ada Logics. В ходе проведённой работы был восстановлен прерванный более года назад процесс тестирования в OSS-Fuzz. С 1.1 до 2.4 млн строк кода увеличен охват кодовой бызы, вовлечённой в fuzzing-тестирование. Также был расширен используемый для fuzzing-тестирования инструментарий, а число применяемых для проверки fuzzing-движков увеличено с 12 до 15...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60707
> 12 новых проблем... и ВСЕ проблемы с памятью!
LLVM же на плюсах написан.
А плюсы должны уметь в память, это же не сишка. Что у них пошло не так?
То что плюсы в память лучше чем сишка, не значит что они идеальны.
Особенно если приходят какие-то покалеченные дыряшкой и начинаю разводить "СИ с классами"
А к сожалению таких много((
Если видишь в вакансии 'знание С/С++' на 98% это очередной адепт сишных подходов который решил, что в плюсы он тоже может.
Бла-бла-бла, теоретик херов. Ты хоть код LLVM позырь и найди там CИ с классами
> Если видишь в вакансии 'знание С/С++' на 98% это очередной адепт сишных
> подходов который решил, что в плюсы он тоже может.Скорее значит, что он толком не знает ни Си, ни Си++.
На два миллиона строк это нереально мало. Вероятнее всего это ошибки работы с памятью, которые можно записать в логические.
Инструмент для обнаружения ошибок памяти обнаружил... ошибки памяти. Какая неожиданность!
> LLVM же на плюсах написан.
> А плюсы должны уметь в память, это же не сишка. Что у них пошло не так?Возможно я сделаю твой день, но вон там CVEхи с ошибками работы с памятью - даже на хрусте. Ну, вот, таки - смогли! Осилили. И ариан на безопасной аде - уронили. Ты недооцениваешь креативность двуногих, анон.
2,4 миллиона строк на плюсах - это примерно как в 12 миллионах строках на Си было бы 12 ошибок.
>должны уметь в памятьПереведите пожалуйста ЭТО на нормальный русский язык!
Нет разницы, используется malloc() или его обертка в виде ключевого слова new. В обоих случаях имеем один и тот же указатель.
> Нет разницы, используется malloc() или его обертка в виде ключевого слова new.
> В обоих случаях имеем один и тот же указатель.new может не вернуть указатель, а бросить std::bad_alloc.
>> Нет разницы, используется malloc() или его обертка в виде ключевого слова new.
>> В обоих случаях имеем один и тот же указатель.
> new может не вернуть указатель, а бросить std::bad_alloc.Может, но внутри в любом случае вызывается malloc() и в случае NULL вызывает либо библиотечный обработчик, либо пользовательский. malloc() нынче с субаллокатором внутри, поэтому надобность в new исчезла.
> 2.4 млн строк кода
> 15 fuzzing-движков
> 12 новых проблем, 8 были вызваны ошибками, приводящими к повреждению памятиЭто просто офигенно. Одна ошибка памяти на 300к строк кода.
Великолепный результат.
Думаю другие проекты о таком и мечтать не могут.
Вот оно превосходство современных плюсов (C++17) над Сишкой.
Каждому известно, что если нужна безопасность, нужно обратиться к Майкрософт.
Удивительно мало уязвимостей. Вот что значит когда разработчики пишут на плюсах, а не чистых сях, обладают высокой квалификацией и используют статический анализ.
И оказывается никакой Rust для этого не нужен.
Его пришлось продвигать: писатели на C не хотели переходить на C++. А теперь будут на Rust.
Это Линус не хотел в одном проекте мешать идиомы RAII и goto error, но в угоду сообществу подвёл под это удивительную теоретическую базу. На чём теперь будут - это интересный вопрос. Удивительным образом Projected EOL всех последних LTS совпали с Dec, 2026. Что-то не припоминаю такого раньше.
>Удивительным образом Projected EOL всех последних LTS совпали с Dec, 2026. Что-то не припоминаю такого раньше.Теория заговора :)
Не будут. Перейдут на плюсы, го, котлин, сисярп, да хоть бидон, но не раст
Оказывается аналитики опеннета так и не поняли, что раст нужен не для написания безопасного кода, а для неписания небезопасного.
Понимаю, что двойное отрицание, для некоторых, сложная ментальная конструкция, но призываю её хотя бы попытаться понять.
Безопасно можно писать на любом ЯП, это вроде очевидно, но Раст бьёт разработчика по рукам и вставляет палки в колеса в опасных местах, в отличии от с/с++, где компиляторам вообще по барабану что там разраб творит.
https://www.openwall.com/lists/oss-security/2021/05/18/1
Как это связано с тем что я написал? Или тебе нужен язык, который ещё и думать над логикой и архитектурой будет вместо тебя?
А кстати почему компиляторы не пишут на скриптовых языках? Они не критичны к производительности на самом деле. А когда отлаживаете - можно просто отключить оптимизацию и всё равно собирать быстро.
потому что продвинутые компиляторы используют всякие векторные инструкции и прочие специфичные для целевого процессора штуки?
Они эти штуки сами не обязаны использовать в процессе своей работы, они эти штуки генерят на выхлопе своей деятельности. Поэтому, это действительно могут делать и компиляторы, сами написанные на скриптовых. Тут только вопрос скорости компиляции.
Эммм, как раз наоборот. Если ты пытался собрать какой-нибудь крупный проект из исходников, то знаешь, это дело не на пять минут, а на полчаса и больше.
Например, ядро Линукса является таким большим проектом. Или Либрофис. Или Хромиум.
Ага щщщщас, некритичны, как же. Такое может говорить только человек, понятия не имеющий об устройстве современного оптимизирующего компилятора и не имевший дела с крупными проектами.Пойди, собери Webkit/Blink из исходников. Потом расскажешь о впечатлениях.
Плюсовый компилятор на огромном проекте, когда разворачивает все шаблоны, неилюзорно так нагружает проц. И это компилятор написаный на C++. А так да, не критичны к производительности, ага.
Ну да, но он запускается один раз. А при разработке можно не собирать с оптимизациями.
> А кстати почему компиляторы не пишут на скриптовых языках?Потому что пересборка линукскернела растянувшаяся по времени на пару недель - это не очень круто, извини. Не критичны? Ох, серьезно?
То есть всё совсем сильно замедлится?
Ну есть ещё языки с jit.
> То есть всё совсем сильно замедлится?То-есть, скорость продвинутого оптимизера, особенно что-то типа LTO, ворочающего глобальный анализ немеряного куска кода - и жор оперативы этим - даже и в нативном коде бывает очень нетривиальным для больших проектов, и таки - напрягает. Сделать LTO на штуке с линукс керенл требует не комп - а компище. Ну вот реально EPYC топовый с десятками гигз оперативы минимум захочется.
Зато ты только представь себе: четверть кода аннулируется нахрен - совершенно нахаляву, без урона производительности. А то и с бонусом к ней.
> Ну есть ещё языки с jit.
А, ну да, отличная идея во время компила оптимизить не только код который собираем - но и код компилятора. Вместо того чтобы его предкомпильнутым заранее сделать. Ну это то да, эффективно получится. По жору оперативы еще сильнее и нагрузке на проц ибо оптимизить теперь надо еще и код компилера заодно.
Потому что применительно к компиляторам исторически сложился такой критерий - True Thing. Когда компилятор языка Икс написан на языке Икс - это значит, что язык Икс достаточно крут даже для написания компилятора. Из чего следуют совсем другие вопросы про компиляторы скриптовых языков, и некоторых нескриптовых.
>про компиляторы скриптовых языкового, есть такие ЯП "скриптовые"? это те в названиях которых есть слово "script"?
Нет, ещё си, например. Это те, у которых можно указать экзешник в шебанге и он исполнит файл.
исполнит? интепретирует, то есть интерпретируемый ЯП.
"Ch is a C/C++ interpreter and scripting language environment"
русский язык, есть еще литературный язык, стихотворный, жаргонный, мат-перемат.повторите свой комент на жаргонном языке.
> "Ch is a C/C++ interpreter and scripting language environment"почему не manuscripting language (manuscriptum, от лат. manus — «рука» и scribo — «пишу»).
>> "Ch is a C/C++ interpreter and scripting language environment"
> почему не manuscripting language (manuscriptum, от лат. manus — «рука»
> и scribo — «пишу»).Это к авторам интерпретатора вопрос. В стандарте Си не помню требований к транслятору быть "компилятором".
Скрипты могут быть и компилируемыми, вот, к примеру, gdscript вполне скриптовый язык, которому нечего делать за границами среды (но и заменить его нельзя адекватно).Жава интерпретируется, но, в обычном виде -- это скомпилированный байткод для вм. А вот жаваскрипт в обычном виде интерпретируемая форма, которая преобразуется в скомпилированную и нативный код в процессе исполнения.
Кстати, жаву ещё можно скомпилировать (GraalVM) и она будет исполняться без виртуально машины. А если заставить жаву просто исполнять файл, то это скриптовый язык. И в качестве скриптового языка, она даже использовалась в играх ещё лет 20 назад (как питон или луа).
> то это скриптовый язык.я могу назвать его алгоритмическим языком? или процедурным языком? может функциональным? неее мульти-парадигменным языком может? ржавый язык - вот оно как.
ЯП - язык программирования, и никаких СЯ - скриптовый язык.
Русский язык, и никаких литературный, жаргонный, мат-перематный язык.
Нет. Скрипты -- это то, что связывает части на нормальных яп и как правило тормозит и ничего не может по сравнению с ними (в теории и брейнфак полноценный яп). Обычно там ещё виртуальная машина, интерпретатор, зачастую сборщик мусора. Если смотреть с такой стороны, то жава и питон это одно и тоже, скриптятина. А вот го и раст скриптовые языки не в большей мере, чем си.
> Нет. Скрипты -- это тоСкрипт, как и алгоритм, программа, функция, сценарий, инструкция - это "содержимое" (текст) на языке программирования. А "содержимое" на данном языке программирования либо компилируется, либо интерпретируется. Не скриптуется же ведь, чтобы он стал "скриптовым языком" программирования. И языки программирования делят именно по свойству компилируемости или интерпретируемости (язык сломался) :)
Я привёл пример с "полновесными" играми для ПК. Вся логика может быть либо на питоне, либо на луа, либо на жаве, в то время как всей отрисовкой и операциями с железом занимаются более производительные компоненты на низкоуровневых языках. Додиез несколько размывает эти границы, потому что на нём пытаются реализовывать не только "логику", но и "вычисления", и вообще всё, в следствие чего самые примитивные игры тормозят и жрут ресурсы как не в себя.Такое разделение на "полноценные яп" для всего и "игрушечные яп", в которых проще реализовать бизнес-логику, куда более логично. Вот игрушечные яп это обычно и есть скрипты. Взять тот же жс, который впихнули туда, где ему, очевидно, не место. Или перл, который как был языком обработки текста, так и остался. И даже если скомпилировать пхп, он не станет полноценным нескриптовым языком, ведь он занимается буквально тем, что совмещает сишные компоненты в себе.
> Я привёл пример с "полновесными" играми для ПК.В этом то и проблема, вы рассматриваете ЯП с точки зрения "содержимого" и классифицируете их по нему.
> Такое разделение на "полноценные яп" для всего и "игрушечные яп", в которых
> проще реализовать бизнес-логику, куда более логично.Это не допустимо в компьютерной науке, ибо не серьезно.
> Вот игрушечные яп это обычно и есть скрипты. Взять тот же жс
На том же JS можно линуксовый кернель написать, от этого он станет не игрушечным?
> "игрушечные яп"приведу небольшую аналогию с процессорами, если текущий линукс кернель не запустится на каком-нибудь интел 8086 это же не дает ведь нам право говорить, что 8086 "игрушечный цпу".
пс: https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
У брейнфака есть какие-либо перспективы стать неигрушечным через 10 лет, а сегодня он уже общепризнан и востребован мировым сообществом во всех областях применения? Может быть, его копируют тысячи компаний и организаций по всему миру?
> по всему миру?ага, все во всем мире пользуются китайским языком, а остальные игрушки? А что это еще за "ржавый" язык придумали еще и пихают в линукс кернель? Детский сад развели ппц.
Исходя из этой логики должен существовать один ЯП - асм, а все остальные по факту игрушки, с чем я могу быть полностью с вами согласен.
> приведу небольшую аналогию с процессорами, если текущий линукс кернель не запустится на
> каком-нибудь интел 8086 это же не дает ведь нам право говорить,
> что 8086 "игрушечный цпу".Как угодно - но он свое в целом отлетал. Редкие исключения только подтверждают правиль: на данном этапе развития технологий уже мало кто юзает ЭТО именно - всерьез. Это вымирающая легаси технология, типа пятидюймового флопа.
> пс: https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset
Это также весьма немассовая и нишевая штука. А кто-то до сих пор на COBOL программит вообще. Но найти хоть 1 программу на COBOL в диком виде - это еще звезды должны так сложиться вообще. Да что там, некоторые даже паровые машины по приколу собирают. Но вот как основной источник энергии для производства... эээ....
> Да что там, некоторые даже паровые машины по приколу собирают. Но
> вот как основной источник энергии для производства... эээ....вы считаете, что собрать паровый движитель - "раз плюнуть"? "игрушечное" такое изобретение? Я промолчу про то, что ресурсы (материальные и интеллектуальные) необходимы чтобы его собрать. Обычный механический арифмометр не способны собрать, утрата "первобытного" опыта большая проблема, за пиком прогресса неминуема деградация (до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили)
> до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили.Это миф. Мы достоверно не знаем КАК ИМЕННО часть этого было сделано, но мы знаем сразу несколько способов как это могло быть тогда сделано. То есть мы не знаем грубо говоря который из них.
Знаем где и как брали гранит и песчаник, где карьеры (они там рядом в пределах прямой видимости, просто на "туристические" фото не попадают), как сверлили, чем сверлили, как таскали и т.д. Знаем практически вообщё все. И никакх "инопланетных технологий" там для этого не надо. И да, огромные многотонные блоки там буквально только у основания и нижних уровней - выше они мельчают.
И да, мы знаем, что это делали не "рабы за миску маиса" (как ошибочно думали довольно долгое время), а рабочие на зарплате, причём работа считалась "престижной" и стабильной (относительно неплохо "кормили" даже в годы неурожаев).
Короче, хватит плодить этот несчастный миф про "инопланетные технологии пирамид".
> Короче, хватит плодить этот несчастный миф про "инопланетные технологии пирамид".я такого не утверждал.
> вы считаете, что собрать паровый движитель - "раз плюнуть"? "игрушечное" такое изобретение?
> Я промолчу про то, что ресурсы (материальные и интеллектуальные) необходимы чтобы его собрать. > Обычный механический арифмометр не способны собрать, утрата "первобытного" опыта большая проблема, за пиком прогресса неминуема деградация (до сих пор не поймут как они так "игрушечные" пирамиды в пустынях построили)Думаю осилят, и довольно просто.
Тут надо не только знать "как сделать", но и "что сделать".
Школота запросто в майнкрафте пилит многроровневые сумматоры.
Т.е им нужно будет реализовать тоже самое, но в других ресурсах.Любой человек видевший счеты на картинке, сможет их реализовать сотней способов из разных материалов. А вот придумать их с нуля - это будет очень сложно.
Конечно где-то все упрется в карго культ, или в миниатюризацию, или в то что именно эту лекцию по физике прогуливал...
Но представь, что ты попаданец в египет и стал фараоном. (до каких аналогий я докатился /_-)
У тебя есть ограниченные ресурсы (но на пирамиду хватит) и остаточные знания из школы и универа.
С учетом того что медь уже добывается, думаю паровой двигатель у тебя уже заработал лет через 10. Т.к ты знаешь ЧТО нужно сделать.ps я уже молчу что Геронов шар был сделан в 1 веке нашей эры. Это примерно пополам от нас до пирамид.
Просто в тот момент не увидели потенциала, тк труд рабов был дешевле.
> Думаю осилят, и довольно просто.ок
> Тут надо не только знать "как сделать", но и "что сделать".
> Т.к ты знаешь ЧТО нужно сделать.вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем, а теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы обозначаем цифрами 10, а не 00?
>> Думаю осилят, и довольно просто.
> ок
>> Тут надо не только знать "как сделать", но и "что сделать".
>> Т.к ты знаешь ЧТО нужно сделать.
> вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем, а
> теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы
> обозначаем цифрами 10, а не 00?тогда уж 010. А вообще, представь что у тебя тумблеры где везде 000000000 до бесконечности. Прибавляем старший "бит" слева, младший справа, по конвенции. И в путь.
Оставим тут четыре "бита", для наглядности:
0000
----
0001
0002
0003
....
0009
0010
0011
0012
....
0020
....
9999
> Прибавляем старший "бит" слева, младший справа, по конвенции.вот ключевой момент, прибавляем (добавляем) новый разряд, после исчерпания "старшего", а не заранее выстраиваем "нули" слева как незначащие.
> И в путь.
С Богом.
0 - 0
1 - 1
2 - 2
3 - 3
4 - 4
5 - 5
6 - 6
7 - 7
8 - 8
9 - 9
00 - 10 -> вуаля добавил новый разряд, а с какой цифры он должен начинаться? он же новый "из коробки", едем дальше...01 - 11
02 - 12
03 - 13
....0000 - ? какое число?
Так в чем же разница? А не больше чисел я отображу пользуясь 4-мя разрядами? Полная позиционная система счисления. Почему мы отказались от всей "мощности представления" знаками(цифрами) чисел позиционной системы счисления?
пс: Даже Лейбниц не узрел полноты представления, когда писал про "двоичную систему", а в "Книге перемен" как раз изображена эта полнота, они об этом знали.
> вот позиционную систему счисления придумали 2000 лет назад, говорите, что знаем,"возникла во второй половине третьего тысячелетия до н. э. в Древнем Египте (египетская система счисления)"
Слегка побольше 2к лет)
> теперь вопрос, почему "десятое число" (в десятичной позиционной системе счисления) мы
> обозначаем цифрами 10, а не 00?Хм, а о какой из систем речь?
Они развивались из одной идеи, но реализации были слегка разные
"В старинных системах для записи одинакового числа использовались символы, рядом с которыми дополнительно помечали, в каком разряде они стоят. Потом перестали помечать разряды, но число всё равно можно прочитать, так как у каждого разряда есть своя позиция. А если позиция пустая, её нужно пометить нулём. В поздних вавилонских текстах такой знак стал появляться, но в конце числа его не ставили. Лишь в Индии нуль окончательно занял своё место, эта запись распространилась затем по всему миру. "
> Слегка побольше 2к лет)эт к слову сказано было
> Хм, а о какой из систем речь?
написал вроде - в десятичной позиционной системе счисления
> А если позиция пустая, её нужно пометить нулём.
откуда такое правило? откуда появляется пустой разряд? не бывает пустого разряда.
> В поздних вавилонских текстах такой знак стал появляться, но в конце
> числа его не ставили. Лишь в Индии нуль окончательно занял своё
> место, эта запись распространилась затем по всему миру. "909 - разве 0 во втором разряде это ноль? 909 = 900 + 00 + 9?
>Жава интерпретируетсятам два этапа, первый компиляция в байт-код, а дальше интерпретация байт-кода (не исполнение).
"Скриптовые языки" было в сообщении, на которое я отвечал. Скорее всего, автор имел ввиду интерпретируемые. От чего смысл моего ответа особо не меняется - современные интерпретаторы обычно предварительно компилируют исходный текст в байт-код.
ну дык надо брать в таком случае в кавычки (как в данном коменте), ибо возникает вопрос
Мне надо было, что бы спрашивающий меня понял, при этом не забивать ему голову лишним. Для чего написаны первые два предложения.Для любителей поспорить в третьем было буквально вот что: "Из чего следуют совсем другие вопросы про компиляторы скриптовых языков, и некоторых нескриптовых."
и вопрос последовал.)
> Для любителей поспоритьа в чем спор то? вы хотите мне доказать существование "скриптовых" языков? Выше я пояснил почему не бывает таких языков. "Скрипт" от слова scribo — «пишу», то есть бывает "пишуший" и не "пишуший" языки?
>> Для любителей поспорить
> а в чем спор то? вы хотите мне доказать существование "скриптовых" языков?Я хочу, что бы ты наконец уяснил. Когда ты задаёшь риторический вопрос, то мне очевидна попытка повернуть разговор в нужное тебе русло. Соответственно, именно тебе лучше знать, в чём твой спор и что ты хотел себе доказать.
> Выше я пояснил почему не бывает таких языков. "Скрипт" от слова
> scribo — «пишу», то есть бывает "пишуший" и не "пишуший" языки?Вот потому скриптом на жаргоне называют файлик, который быстро накатали (или подправили) и запустили на исполнение. Обычно это интерпретируемый язык. И даже если бы скриптом называли пьесу Шекспира, это бы не изменило суть моего ответа - он про True Thing, а не про забивание головы спрашивающего ненужной ему терминологией.
> И даже если бы скриптом называли пьесу ШекспираВот именно назвали пьесу (текст, содержимое), а не язык (англ) на котором написан этот "скрипт". Мне продолжать пояснять или на этом остановимся?
PyPy
ага точно, ты когда-нибудь билдил что-то большее чем хелоуворд?сишные проекты вообще медленно билдятся
но даже какой-нибудь моно когда собирает ассембли не блещет скоростью
> Они не критичны к производительности на самом деле.Для хоум юзера — некритичны. А вот на работе, где сборочные фермы для CI стоят от нескольких сотен тысяч баксов — очень даже критичны.
Куда больший интерес сейчас представляет AI-Powered Fuzzing. Натравил модель на свой код, вуаля - все безопастно аж дальше некуда при почти нулевых усилиях. Вот оно, будущее безопастности.
Опять "волшебные" таблетки под новой упаковкой продают.
ИИ не магия, работать за вас не будет, по эффективности проигрывает классическим алгоритмам, а фьюзинг итак время и ресурсоъемкий.
> Куда больший интерес сейчас представляет AI-Powered Fuzzing. Натравил модель на свой код,
> вуаля - все безопастно аж дальше некуда при почти нулевых усилиях.
> Вот оно, будущее безопастности.Вон там в соседней новости - будущее безопасности. Когда ты скачал модель, запустил, она тебя раз@#$ла нафиг - и байбай.
Доверять ИИ безопасность кода?Это тому самому ИИ который часто любит выдумывать и глючить..
Идея на самом деле неплохая.
Просто скармливаете нейронке все CVE, найденные в ядре, за последние 10-20 лет и пусть ищет "похожие конструкции".
А там уже человек глазенками просмативает.
И лжеИИ в определенном моменте зацикливается.