Настало время статей про баги в открытых проектах на TypeScript: Проверка исходников VSCode.
🔥2
Реинкарнация старой статьи: Сопротивляйтесь добавлению в проект новых библиотек — 10 лет спустя. Актуально, так как люди (а теперь и ИИ), тащат разное в проект, не думая, как потом это быстро аккуратно сопровождать, а уж тем более сертифицировать, если понадобится.
Наш самолет имеет на борту бассейн, танцевальную площадку, ресторан, уютные зоны отдыха, зимний сад... Уважаемые пассажиры, пристегните ремни, теперь мы попытаемся со всей этой ***** влететь.
🔥4👍1
Рассылка для С++ разработчиков на тему работы с legacy-кодом
Команда YADRO предложила мне стать одним из авторов рассылки для С++ программистов, посвящённой работе с унаследованным кодом. C++ легаси — это же моё любимое! Естественно, я согласился.
Рассылка начнётся с 15 сентября 2026, так что вот вам ссылка на лендинг и регистрацию: ~GHOST IN THE CODE().
Вас ждёт серия из 7 писем о том, какие инструменты и процессы помогают наладить работу с легаси-кодом. Их подготовят такие эксперты, как Антон Полухин, Константин Владимиров, Александр Иргер, Юлия Головчанская, Алексей Веселовский, Илья Шишков и я :)
Помимо информации, обещают квесты от авторов. Ищите задачи в конце каждого письма и присылайте ответы на почту engineer@yadro.com.
P.S. Кстати, на тему квизов. Напоминаю про наши спрятанные пасхалки в релизе PVS-Studio 8.00.
Команда YADRO предложила мне стать одним из авторов рассылки для С++ программистов, посвящённой работе с унаследованным кодом. C++ легаси — это же моё любимое! Естественно, я согласился.
Рассылка начнётся с 15 сентября 2026, так что вот вам ссылка на лендинг и регистрацию: ~GHOST IN THE CODE().
Вас ждёт серия из 7 писем о том, какие инструменты и процессы помогают наладить работу с легаси-кодом. Их подготовят такие эксперты, как Антон Полухин, Константин Владимиров, Александр Иргер, Юлия Головчанская, Алексей Веселовский, Илья Шишков и я :)
Помимо информации, обещают квесты от авторов. Ищите задачи в конце каждого письма и присылайте ответы на почту engineer@yadro.com.
P.S. Кстати, на тему квизов. Напоминаю про наши спрятанные пасхалки в релизе PVS-Studio 8.00.
🔥4
Forwarded from СВД ВС
Уже завтра, 9 сентября в 12.00 вместе с партнерами PVS-Studio проведём вебинар:
«Применение ЗОСРВ «Нейтрино» и PVS-Studio для разработки ПО согласно требованиям МЭК 61508»
Разберём, как подходы к разработке ПО для ЗОСРВ «Нейтрино» соотносятся с требованиями МЭК 61508 и какую роль в обеспечении функциональной безопасности играет статический анализ.
Наши партнёры представят обзор новой мажорной версии PVS-Studio 8.0 и дальнейшие направления развития.
Поговорим не только о стандартах, но и покажем, как инструменты разработки и статического анализа работают вместе на практике.
👉 Подключайтесь к вебинару вместе с экспертами СВД ВС и PVS-Studio.
🔗 Регистрация:
#Безопасная_разработка #Партнеры #Вебинары
«Применение ЗОСРВ «Нейтрино» и PVS-Studio для разработки ПО согласно требованиям МЭК 61508»
Разберём, как подходы к разработке ПО для ЗОСРВ «Нейтрино» соотносятся с требованиями МЭК 61508 и какую роль в обеспечении функциональной безопасности играет статический анализ.
Наши партнёры представят обзор новой мажорной версии PVS-Studio 8.0 и дальнейшие направления развития.
Поговорим не только о стандартах, но и покажем, как инструменты разработки и статического анализа работают вместе на практике.
👉 Подключайтесь к вебинару вместе с экспертами СВД ВС и PVS-Studio.
🔗 Регистрация:
#Безопасная_разработка #Партнеры #Вебинары
🔥3
Однажды Эрнест Хемингуэй поспорил, что напишет самый короткий рассказ о том, как испортили Хабр. Вот он:
OpenAI только что решили задачу тысячелетия и представили решение задачи Навье — Стокса
Возможно OpenAI решили одну из задач тысячелетия: разбираемся в слухах вокруг уравнения Навье-Стокса
Нейронный Навье-Стоксгейт: скандал с OpenAI вокруг решения «задачи тысячелетия» на $1'000'000
Или Хабр начнёт бороться с нейромусором, или умрёт :(
OpenAI только что решили задачу тысячелетия и представили решение задачи Навье — Стокса
Возможно OpenAI решили одну из задач тысячелетия: разбираемся в слухах вокруг уравнения Навье-Стокса
Нейронный Навье-Стоксгейт: скандал с OpenAI вокруг решения «задачи тысячелетия» на $1'000'000
Или Хабр начнёт бороться с нейромусором, или умрёт :(
🔥4🤣2❤🔥1👏1
На случай, если вы пропустили информацию об одной из наших интеграций PVS-Studio с внешними системами. См. статью.
🔥5
Сегодня записи сразу двух вебинаров на тематику создания надёжных программных проектов.
Автоматизация контроля качества и безопасности ПО
Применение ЗОСРВ "Нейтрино" и PVS-Studio для разработки ПО согласно требованиям МЭК 61508
Автоматизация контроля качества и безопасности ПО
Вебинар посвящен тому, как встроить практики качества и безопасности в ежедневный цикл разработки. Эксперты PVS-Studio и Apsafe рассказали, почему статический анализ и автоматизированные проверки стали доступными инструментами для любой команды и как регулярный контроль безопасности помогает успевать за современным ритмом релизов без перестройки CI/CD.
Валерий Филатов (Developer Advocate, PVS-Studio) рассказал в своем докладе "Зачем платить за то, что уже работает?" о том что когда-то код-ревью, автотесты и CI/CD казались лишней бюрократией — дорогой и доступной немногим. Со временем выяснилось, что без них инциденты обходятся дороже, чем сама практика, а инструменты подтянулись настолько, что теперь это может себе позволить любая команда. На примере статического анализа посмотрели, почему Best Practices давно перестали быть недостижимым идеалом.
Виктор Тимашков (руководитель группы Apsafe) в своем докладе "Безопасность приложения это не разовая проверка, а ритм релиза" объяснил, что разовые пентесты и квартальные аудиты не успевают за поставкой: код уходит в прод чаще, чем его успевают «проверить снаружи». Разобрали, почему контроль должен повторяться вместе с релизом, что меняется в процессе разработки и как облачный контур (на примере Apsafe) встраивает проверки в этот ритм без перестройки CI/CD.
Применение ЗОСРВ "Нейтрино" и PVS-Studio для разработки ПО согласно требованиям МЭК 61508
На вебинаре разобрали подходы к разработке функционально безопасного ПО для ЗОСРВ «Нейтрино» в соответствии с требованиями МЭК 61508 и показали, какую роль в этом процессе играют инструменты статического анализа.
В первой части поговорили о принципах разработки ПО для «Нейтрино», рассмотрели требования МЭК 61508 к инструментальным средствам, и продемонстрировали работу PVS-Studio в комплекте разработчика «Нейтрино».
Во второй части подробнее остановились на статическом анализе как инструменте для обеспечения безопасности. Разобрали требования МЭК 61508 и МЭК 26262, их связь со стандартами MISRA и рассмотрели, как PVS-Studio помогает контролировать качество и соответствие кода требованиям стандартов.
В завершение рассказали о новой мажорной версии PVS-Studio 8.0: рассмотрели ключевые изменения и нововведения релиза и обозначили дальнейшие направления развития инструмента, включая функциональную безопасность.
🔥3👍2
Тяжело, когда ты программист и привык чётко воспринимать условия в повествовании :)
Из описания конференции.
Мы не делаем
* Без воды и теории из интернета
* Без курсов и инфоцыган
* Не продаём и не рекламируем со сцены
Из описания конференции.
Мы не делаем
* Без воды и теории из интернета
* Без курсов и инфоцыган
* Не продаём и не рекламируем со сцены
😁4👌1
Всем привет. Я уже делал цикл из 5 вебинаров про ГОСТ Р 71207—2024 (Статический анализ программного обеспечения): Общее описание и актуальность, Терминология, Критические ошибки, Технологии анализа кода, Процессы.
С тех времён я переосмыслил некоторые моменты. Прошли испытания статических анализаторов. Вышел ГОСТ Р 56939—2024 и так далее.
Поэтому меня посетила мысль вновь сделать обзор стандарта, но немного в другом формате: брать разные фрагменты из него и комментировать/обсуждать. Образно говоря, читать и разбирать ГОСТ вслух с интонацией, комментариями и отсылками :)
Это можно сделать по-разному:
1. Просто сесть и сделать записи. Потом это можно будет слушать как мини аудио-книгу/подкаст.
2. Сделать стрим, где попутно будут задаваться вопросы по разбираемому месту.
Второй вариант подразумевает, что это будет интересно аудитории и люди соберутся, иначе теряется смысл и проще пойти по первому пути. Решил сделать предварительный опрос.
С тех времён я переосмыслил некоторые моменты. Прошли испытания статических анализаторов. Вышел ГОСТ Р 56939—2024 и так далее.
Поэтому меня посетила мысль вновь сделать обзор стандарта, но немного в другом формате: брать разные фрагменты из него и комментировать/обсуждать. Образно говоря, читать и разбирать ГОСТ вслух с интонацией, комментариями и отсылками :)
Это можно сделать по-разному:
1. Просто сесть и сделать записи. Потом это можно будет слушать как мини аудио-книгу/подкаст.
2. Сделать стрим, где попутно будут задаваться вопросы по разбираемому месту.
Второй вариант подразумевает, что это будет интересно аудитории и люди соберутся, иначе теряется смысл и проще пойти по первому пути. Решил сделать предварительный опрос.
Сегодня у меня для любителей C++: Каждая идиома когда-то была проблемой.
А для Java-разработчиков: 96-й подкаст Javaswag: Gradle, плагины для Minecraft и статический анализ в PVS-Studio.
Красивый и надёжный код почти никогда не рождается с первого раза. Сначала появляются ошибки, а уже потом – идиомы, которые помогают их избегать. На вебинаре рассмотрели реальные фрагменты кода из открытых проектов на языке C++, нашли в них проблемные места с помощью статического анализа, и разобрали более 10 идиом и паттернов, которые позволят защитить ваш код.
А для Java-разработчиков: 96-й подкаст Javaswag: Gradle, плагины для Minecraft и статический анализ в PVS-Studio.
Обсудили, как войти в Java через моды и серверы Minecraft, почему мир кубов живет на Netty и Gradle, как грамотно организовать мультимодульные проекты с помощью build-logic и type-safe accessor'ов, а также заглянули под капот разработки статических анализаторов кода (от поиска багов и Taint-анализа до соответствия ГОСТам).
👍4
Бестиарий программирования pinned «Всем привет. Я уже делал цикл из 5 вебинаров про ГОСТ Р 71207—2024 (Статический анализ программного обеспечения): Общее описание и актуальность, Терминология, Критические ошибки, Технологии анализа кода, Процессы. С тех времён я переосмыслил некоторые моменты.…»
Пример, как идеология педантичности стандарта MISRA C защищает от ошибок
В C литерал
V2648 Use NULL macro instead of literal zero for pointers.
Если заменить некоторые
Правило, кажется, просто украшательством стиля написания кода. Лишнее ограничение при написании кода... Какой практический прок? Давайте посмотрим, как такое предупреждение помогает выявить реальную ошибку.
Обратите внимание на тип переменной
Благодаря осмотрительной педантичности найдена реальная ошибка.
На самом деле, PVS-Studio и раньше эту ошибку находил с помощью другой диагностики – V527 It is odd that the '\0' value is assigned to 'char' type pointer. Но здесь именно хотелось продемонстрировать, как работают и помогают MISRA правила. Вообще ситуация, что один и тот-же баг выявляется разными детекторами, вполне частая ситуация и удивляться этому не стоит.
Почему я про MISRA вспомнил?
Во-первых, мои коллеги сейчас занимаются подготовкой квалификационного пакета PVS-Studio согласно ГОСТ Р МЭК 61508 и ГОСТ Р ИСО 26262 по поддержке MISRA C:2012 и MISRA C:2023.
Во-вторых, 23 сентября я буду с докладом "Анализатор PVS-Studio как средство достижения целей верификации ГОСТ Р ИСО 26262-6" на форуме "Безопасность транспортных средств". Приглашаю посетить мероприятие и мой доклад.
В C литерал
0 можно присваивать как численным типам, так и указателю (вместо NULL). Правило MISRA C 2012/2023 11.9, которое говорит, что нужно использовать именно NULL, может казаться избыточным. Например, здесь:typedef struct FT_Outline_
{
short n_contours; /* number of contours in glyph */
short n_points; /* number of points in the glyph */
FT_Vector* points; /* the outline's points */
char* tags; /* the points flags */
short* contours; /* the contour end points */
int flags; /* outline masks */
} FT_Outline;
....
static const FT_Outline null_outline = { 0, 0, 0, 0, 0, 0 };
V2648 Use NULL macro instead of literal zero for pointers.
Если заменить некоторые
0 на NULL никому лучше не станет.static const FT_Outline null_outline = { 0, 0, NULL, NULL, NULL, 0 };Правило, кажется, просто украшательством стиля написания кода. Лишнее ограничение при написании кода... Какой практический прок? Давайте посмотрим, как такое предупреждение помогает выявить реальную ошибку.
typedef char FAR * FAR * png_charpp;
....
png_size_t
png_check_keyword(...., png_charpp new_key)
{
....
if (key_len > 79)
{
png_warning(....);
new_key[79] = '\0'; // <= V2648
key_len = 79;
}
....
}
Обратите внимание на тип переменной
new_key – это указатель на указатель. Из-за опечатки, терминальный ноль обнуляет указатель, а не записывается в строку. Правильный вариант кода:(*new_key)[79] = '\0';Благодаря осмотрительной педантичности найдена реальная ошибка.
На самом деле, PVS-Studio и раньше эту ошибку находил с помощью другой диагностики – V527 It is odd that the '\0' value is assigned to 'char' type pointer. Но здесь именно хотелось продемонстрировать, как работают и помогают MISRA правила. Вообще ситуация, что один и тот-же баг выявляется разными детекторами, вполне частая ситуация и удивляться этому не стоит.
Почему я про MISRA вспомнил?
Во-первых, мои коллеги сейчас занимаются подготовкой квалификационного пакета PVS-Studio согласно ГОСТ Р МЭК 61508 и ГОСТ Р ИСО 26262 по поддержке MISRA C:2012 и MISRA C:2023.
Во-вторых, 23 сентября я буду с докладом "Анализатор PVS-Studio как средство достижения целей верификации ГОСТ Р ИСО 26262-6" на форуме "Безопасность транспортных средств". Приглашаю посетить мероприятие и мой доклад.
👏5
"Лаборатория Касперского" разрабатывает микроядерную операционную систему KasperskyOS в соответствии с принципом Secure by Design (конструктивная безопасность). Этот принцип предполагает, что защищённость системы закладывается на уровне её архитектуры. К качеству и надёжности операционной системы предъявляются высокие требования, а доверенные компоненты проходят тщательную проверку, одним из этапов которой является статический анализ кода.
"Лаборатория Касперского" использует PVS-Studio в разработке операционной системы KasperskyOS с 2016 года. За это время некоторые обращения разработчиков в нашу поддержку превратились в новые функции анализатора, доступные теперь всем пользователям PVS-Studio. Разбираем пять таких случаев и показываем, как обратная связь корпоративного клиента влияет на развитие продукта.
"Лаборатория Касперского" использует PVS-Studio в разработке операционной системы KasperskyOS с 2016 года. За это время некоторые обращения разработчиков в нашу поддержку превратились в новые функции анализатора, доступные теперь всем пользователям PVS-Studio. Разбираем пять таких случаев и показываем, как обратная связь корпоративного клиента влияет на развитие продукта.
🔥5