Comments 57
ГОСТ... соответствие... хм... паразитировать на госбюджете задумали?
А что на нем ещë делать? Госбюджет паразитирует на людях, люди паразитируют на госбюджете, смыть, повторить.
Странные мысли. Мы 15 лет успешно разрабатываем и продаём PVS-Studio без всяких ГОСТ. Однако, раз уж стандарт появился, странно не обратить на это внимание и не доработать напильником PVS-Studio, чтобы ему соответствовать. Благо хоть это и потребовало несколько месяцев доработок, ничего сверх особенного не пришлось делать. Анализатор уже был мощен, просто нужно было например, классифицировать предупреждения по типу перечисленным там критических ошибок. Естественно такой классификации в инструменте до ГОСТ не существовало и не могло существовать.
Какие ГОСТы, такие и мысли, просто так ГОСТы не делают, значит это кому-то нужно. Да и в поиске данный ГОСТ коррелирует только с PVS-Studio, ГОСТируют только вещи планируемые к регулировке со стороны государства - зачем регулировать разработку подобной штуки? Затем чтобы применять ее в госсекторе. Как применять ее в госсекторе? Наверное навязывать всем разработчикам задействованным в госсекторе и выполняющим госзаказы.
ИМХО
Имею мнение - хрен оспоришь.
ГОСТ на болты
... ГОСТируют только вещи планируемые к регулировке со стороны государства - зачем регулировать разработку подобной штуки? Затем чтобы применять ее в госсекторе. Как применять ее в госсекторе? Наверное навязывать всем разработчикам задействованным в госсекторе и выполняющим госзаказы...
А я думал, чтобы болты с гайками сходились :)
Прочитай ГОСТ :) Там совершенно адекватные вещи про улучшение процессор разработки ПО. Если не понятна актуальность, что могло быть не так со статическим анализом, то некоторые моменты я здесь разбирал.
Хороший статический анализатор (насколько видел их статьи). Увеличивает качество ПО, от внедрения в разработку.
Теперь госуха связанная ГОСТ-ами может его использовать. Это хорошо.
К чему язвительные комментарии - с технической точки зрения мне совсем не понятно.
Один из лучших, хотя большие языковые модели уже на пятки наступают.
И без ГОСТов могли использовать.
Да, так - смотрю во что данный подход от 1С вылилися и сколько ресурсов и сил впустую тратится людьми, печально все это... Потом дойдет до того, что будут обновлять и гонять по кругу варнинги в двояких ситуациях и будут заставлять их править, и штрафы, штрафы, штрафы... )
Так и вижу: "ЧатГПТ, проверь этот код на соответствие ГОСТ..."
Что-то подобное, я уже слышал, когда говорил вам, что поддерживать нужно не только MSVS и плюсы. Еще через десять лет никуда не денетесь - прикрутите нейронки )
Так все есть давно. И другие системы, и другие языки. Не понимаю коммент.
Когда я предложил, не было и тоже посмеялись, а потом все равно сделали. Чего не понятного?
Не посмеялись, а было "не время". Потом время настало и сделали. Так и тут. Все сделаем.
В следующем году кстати ещё несколько языков планируем поддержать. Приходи к нам на работу может опять? Как в старые добрые?
Ну уж нет уж.
А какие языки, если не секрет? Древние и склонные к наличию багов в коде (типа PHP или Python) или набирающие популярность современные (типа Dart, Rust, Kotlin или что-то в этом духе)?
Да вот решаем пока. Есть варианты. Какие хочется?
Для Rust было бы неплохо. Есть Clippy, но там, ЕМНИП, нет никаких кросс-функциональных вариантов анализа, только в пределах одной функции. Ну и некоторые ошибки, которые PVS-studio детектирует, от языка слабо зависят (вроде V6004)
Delphi 7 есть несколько лямов строк, а SAST нет
Мне? Это будет нерепрезентативно. Ну, допустим, Pascal/Delphi.
А если смотреть по популярности и потенциально "бажности" экосистемы, то наверно Python, PHP или Ruby, но вторые два уже "устаревающие".
Если по современным, то наверно Go или Rust, но у меня нет совершенно никакой статистики, что там со статическим анализом и багами в целом.
О, решение на 100% - 1С :-D
хотя большие языковые модели уже на пятки наступают
Они никогда не заменят статические анализаторы, потому что:
а) никакая модель, какой бы навороченной она бы не была, не может диагностировать паттерны ошибок, которых не было в обучающих данных, и добавить новое правило в анализатор проще, чем дообучать модель на многих примерах.
б) LLM склонны к галлюцинациям, причём довольно убедительно выглядящим, а от качественного статанализатора ждут низкого false positive rate.
Ну да, опыт показывает, что они ещё и просто криво работают.
Максим, привет! Рад тебя видеть! И приятно осознавать, что бывшие сотрудники даже через 10 лет следят за делами компании. Значит мы не зря работаем.
Не пойму только зачем занудствуешь? Ты вроде бодрый парень был всегда. А комментарий как будто мимо подъезда прошел.
Какая ужасно длинная статья...
Прогонял я свои проекты, пока была лицензия в конторе. Думал, щас натравлю, и все проблемы сразу решатся.
Натравил, а в результатах... Ничего. Ни одного значимого предупреждения.
Зато если запустить санитайзер gcc, вот он вдоволь срабатывает.
Может тут другой бизнес? выпустить ГОСТ, впихнуть требование выполнения этого ГОСТ везде где сможешь и дальше фактически за лицензионный сбор снимать это требование 🤣🤣 В общем это не про анализ и ошибки 🤷 Встречался с таким подходом в иных сферах 🤷 Хороший бизнес ;) но тоже надо уметь 🤣🤣
Это не так работает. Сейчас в целом идёт тренд на стандартизацию и регулирование процессов безопасной разработки ПО. ГОСТ про статический анализ – это небольшая часть этого процесса. Будут вводиться новые требования и стандарты. Например, буквально вчера 20.12.2024 введён в действие обновлённая версия ГОСТ Р 56939-2024 – Защита информации. Разработка безопасного программного обеспечения. Общие требования.
Гм.. Раз была лицензия в конторе, так быть может основные ошибки уже были исправлены? :) Ну или вариант, код уже был качественным, что тоже бывает.
В моем проекте, в котором я лид, который я начинал с пустого репозитория, без моего ведома этого произойти не могло.
Насчёт качественного. Ну вот после этого я и задумался, что есть качественный код, видимо для исполнения этого критерия достаточно отсутствия ошибок копипасты, перепутывания = с == и подобного.
Зато если запустить санитайзер gcc, вот он вдоволь срабатывает.
Если вы именно санитайзер имели в виду, то тут как раз нет ничего удивительного: статические анализаторы и динамические детектируют разные баги, с довольно небольшим пересечением.
Привет. А планируете участвовать в анонсированных ФСТЭК испытаниях средств статического анализа?
А на этот вопрос коллеги ответят в понедельник с фактурой уже. Знаю, что весь год работаем в этом направлении. Но не хочу ляпнуть мимо чего-то.
Над этим начинанием пока не работаем, так как собственно как я понимаю совсем недавно прозвучало в анонсах задач ФСТЭК на 2025-2030 год. Я думаю, имеется в виду доклад от ФСТЭК про совершенствование безопасности системного ПО, где говорилось про "развитие набора квалифицированных тестов для инструментов жизненного цикла безопасного ПО". Примем мы какое-то участие во всём этом пока не понятно. Мы просто не знаем, как и что будет.
Другое дело, что мы уже поработали и продолжим работу над лучшим соответствием критерием, изложенным в ГОСТ. Добавим новые детекторы для выявления критических ошибок, можно поработать над анализом косвенных вызовов и так далее.
Добрый день. Речь идёт о вот этом выступлении на конференции ИСП РАН
https://vkvideo.ru/video-214485707_456239018?t=3h39m50s&ref_domain=isprasopen.ru
Люблю комментарии на Хабре. Сто лет не общался здесь, а все как раньше. Если ты не уверен в том, что делаешь, то тебе напихают полную панамку комментариев. И ты можешь дать слабину и засомневаться в себе.
Хорошо что мы знаем, что делаем. И готовы спокойно делать то, что нужно нашим клиентам. А не слушать людей из интернета.
Тут народ просто слишком хорошо умеет в технологии, но не всегда умеет в бизнес. ГОСТ это больше про бизнес, и лишь отчасти про технологии. Это начинает задевать самолюбие тех, кто ещё не всё понял про бизнес в РФ, насколько сильно он захвачен крупными компаниями, иногда в связке с гос структурами (см Ланит и тп). А в целом, если у отличного инструмента PVS Studio появятся новые заказчики, пусть и гос, это же отлично, так что всем, кто выше написал "какие вы нехорошие, раз у вас такие методы продвижения", останется только утереться (или учиться на вашем примере, как надо правильно продвигаться).
К сожалению, PVS-Studio спотыкается на простых примерах. Передача неинициализированной переменной по ссылке или указателю приводит к ложноотрицательному результату.
#include <iostream>
void foo(int& value)
{
value *= value;
}
int main()
{
int a;
foo(a);
std::cout << a;
return 0;
}Видел аналогичный вопрос на stackoverflow про Cppcheck (название топика: Why are pointers difficult for static analysis even in simple cases). И пример там схожий был и Cppcheck аналогично баг не находил. Сейчас топик удалён. Не Вы случаем были? :)
А ответ, это не совсем простой пример, как может казаться со стороны. Знаем про такое, будем со временем дорабатывать.
Cppcheck именно с этим примером справляется. И нет, раньше я этим вопросом не задавался. Только сегодня решил сделать простые примеры для студентов на п.6.5 ГОСТ 71207 и столкнулся с тем, что в моих примерах из десятка строк анализаторы ничего не находят.
Кстати, с синтетическими тестами надо быть аккуратными :) Помню была у меня одна старая заметка: Почему я не люблю синтетические тесты. :)
Подозреваю, что до полной аналитической интерпретации синтаксического дерева дело не дошло и вряд ли дойдет, поскольку это накладно, а эвристики спотыкаются.
Зато нейросеть без проблем справляется (взял llama-3.3-70b-instruct, хотя запустить ее дома пока еще тоже довольно накладно =):
Привет, проведи пожалуйста статический анализ кода ниже и дай список предупреждений:
....код выше....
Ответ:
Вот список предупреждений, полученных после статического анализа кода:
Неинициализированная переменная: Переменная
aне инициализирована перед передачей в функциюfoo(). Это может привести к неопределённому поведению, поскольку функцияfoo()использует значениеaв вычислениях.Неопределённое поведение: Поскольку
aне инициализирована, результат операцииvalue *= valueтакже неопределён. Это может привести к непредсказуемым результатам при выводе значенияaвmain().Отсутствие проверки ошибок: Функция
foo()не проверяет, является ли входной аргумент допустимым (например, не является ли он NaN или бесконечным). Хотя в данном случае это не критично, в более сложных сценариях отсутствие проверок может привести к ошибкам.Нет проверки на переполнение: Если
aинициализирована большим значением, операцияvalue *= valueможет привести к переполнению, что приведёт к неопределённому поведению.
Ну так-то тот же clang analyzer, даже довольно древний, вполне справляется с этим примером:
$ scan-build make
scan-build: Using '/usr/bin/clang-8.exe' for static analysis
/usr/bin/../libexec/c++-analyzer -o tst tst.cpp
tst.cpp:4:11: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage
value *= value;
~~~~~ ^
1 warning generated.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2024-12-24-005215-1797-1' to examine bug reports.
Отсутствие проверки ошибок: Функция
foo()не проверяет, является ли входной аргумент допустимым (например, не является ли он NaN или бесконечным). Хотя в данном случае это не критично, в более сложных сценариях отсутствие проверок может привести к ошибкам.
Типичный пример галлюцинаций LLM, ну какой к черту NaN или бесконечность у int, что он несет вообще.
Да, ляпнула она лишнего, но не все сразу, к тому же она далеко не из самых продвинутых, просто взял из тех, что полностью открыты.
chatgpt-4o-latest-20241120 уже лучше выдал, но он закрытый:
Ключевые предупреждения:
Использование неинициализированной переменной (
int a).Отсутствие проверки на переполнение в операции
value *= value.Отсутствие поясняющих комментариев.
Возможное улучшение читаемости кода (добавление проверок и переименование функции).
gemini-2.0-flash-thinking-exp-1219 совсем краток:
Предупреждения:
Использование неинициализированной переменной ...
Многословно слишком, NaN какой-то приплетён... Кстати, ради интереса напиши, что если попробовать как-то так сделать:
#define INT static int
#include <iostream>
void foo(int& value)
{
value *= value;
}
int main()
{
INT a;
foo(a);
std::cout << a;
return 0;
}
Вывод предупреждений
Переменная
aне инициализирована явно — рекомендуется инициализировать её значением0.Использование макроса
#define INT— плохая практика, лучше использоватьtypedefилиusing.Передача потенциально неинициализированного значения по ссылке — хотя здесь UB нет из-за статического контекста, рекомендуется явная инициализация.
Использование макроса #define INT — плохая практика, лучше использовать typedef или using.
Плохая практика - это конечно все здорово, но только ни typedef ни using в данном случае не годятся.
Передача потенциально неинициализированного значения по ссылке — хотя здесь UB нет из-за статического контекста, рекомендуется явная инициализация.
Забавная формулировка - "потенциально неинициализированного". Здесь никаких "потенциально" нет, а переменная однозначно инициализирована. Итого одна более-менее полезная диагностика из трех, я бы сказал, да и та по большому счету вкусовщина, относящаяся скорее к coding conventions, чем непосредственно к корректности кода.
PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)