Старайтесь не писать строки кода, которые не помещаются на экран (часть 1 из 2)

Встретили баг, который одновременно демонстрирует, как "код-колбаса" притягивает ошибку, эффект последний строки и проблему неудачного copy-paste.

Мы не только реализуем в PVS-Studio новые диагностические правила, но и постепенно дорабатываем старые. Например, недавно в C#-анализаторе мы улучшили одну из самых старых диагностик — V3001, научив её корректнее определять случаи, когда дополнительные скобки ни на что не влияют. Результат — выявление новых багов, с одним из которых мы сейчас вас познакомим.

Ошибка найдена в проекте Space Engineers, который входит в базу проектов для регрессионного тестирования нашего анализатора. Мы используем старую зафиксированную версию проекта, так как нам нужно анализировать отличие работы анализатора на одном и том же коде. Но если заглянуть в свежую версию исходного кода, то можно обнаружить, что ошибка по-прежнему присутствует. См. функцию Contains в BoundingBox.cs.

Видите ошибку? Думаю, нет.

А всё почему? Потому, что не надо писать такие длинные нечитаемые строки кода. В них очень легко допустить ошибку, что, собственно, и произошло. Отформатирую и сокращу код.

return (double)this.Min.X + (double)num > (double)sphere.Center.X ||
       (double)sphere.Center.X > (double)this.Max.X - (double)num ||
       ((double)this.Max.X - (double)this.Min.X <= (double)num ||
        (double)this.Min.Y + (double)num > (double)sphere.Center.Y) ||
       ((double)sphere.Center.Y > (double)this.Max.Y - (double)num ||
        (double)this.Max.Y - (double)this.Min.Y <= (double)num ||
       ((double)this.Min.Z + (double)num > (double)sphere.Center.Z ||
        (double)sphere.Center.Z > (double)this.Max.Z - (double)num)) ||
       (double)this.Max.X - (double)this.Min.X <= (double)num ?
         ContainmentType.Intersects : ContainmentType.Contains;

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

Старайтесь не писать строки кода, которые не помещаются на экран (часть 2 из 2)

Обратите внимание на последнюю строчку логического условия:

(double)this.Max.X - (double)this.Min.X <= (double)num

Она повторяет третью строчку. Условие выше заключено в дополнительные скобки, но они ни на что не влияют, так как все проверки объединяются с помощью оператора ИЛИ.

На самом деле в последнем случае должна проверяться координата Z:

(double)this.Max.Z - (double)this.Min.Z <= (double)num

Анализатор PVS-Studio замечает это и выдаёт предупреждение: V3001 There are identical sub-expressions '(double)this.Max.X - (double)this.Min.X <= (double)num' to the left and to the right of the '||' operator.

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

Здесь проявил себя и "эффект последней строки". Опечатки чаще всего появляются в конце однотипных фрагментов кода. Здесь, правда, нельзя говорить про строки, так как строка одна. Но суть та же: ошибка допущена в последней части длинного выражения, состоящего из схожих блоков.

Ошибка возникла из-за copy-paste. Подвыражения, видимо, писались с помощью копирования предыдущих, и в одном из мест в копию не были внесены нужные изменения. Однако это ещё не всё. Вся эта строка с ошибкой ещё раз была размножена копированием, и её можно наблюдать в соседней функции Contains несколькими строками ниже.

Всё то же самое, и анализатор указал на вторую ошибку точно таким же предупреждением.

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

1. Форматированию кода таблицей.

2. Вынесению единообразного кода в функции.

3. Удалению лишних операций. Например, вместо того, чтобы везде выполнять приведение типа (double)num можно было сразу объявить переменную num как double.

4. Регулярному использованию статического анализатора PVS-Studio для дополнительного контроля.

Меня вновь позвали на подкаст Ever Secure. Присоединяйтесь сегодня вечером (11 ноября в 19:00 по МСК).

Запись "Функциональное тестирование" из цикла "Вокруг РБПО за 25 вебинаров". Это 18-й процесс ГОСТ Р 56939-2024, до рассмотрения которого мы добрались вместе с УЦ МАСКОМ.

А ещё на подходе:

Сегодня! Совместный вебинар с CyberCodeReview "Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте". (13 ноября в 15:00, онлайн)

Вебинар "Особенности разработки встроенного ПО по требованиям ФБ" (20 ноября в 15:00, онлайн). ГОСТ Р МЭК 61508, SIL (УПБ), встроенное ПО, MISRA C и т.д.

Митап "Сплошные плюсы. Клуб С++ разработчиков" (25 ноября в 18:00, Москва, оффлайн).

Я там сделаю доклад "Неопределённое поведение: если про него не думаете, это не значит, что его нет".

Второй доклад будет от Александра Асонова(НИЦ «Курчатовский институт») – "Российские операционные системы реального времени семейства Багет".

Приглашаю регистрироваться!

Вроде чёрная пятница, а распродажу PVS-Studio не устроишь. Подобные решения не покупают импульсивно, да и процесс растянут во времени.

Но просится тематичный пост сделать. Давайте так. Если кто-то, приобретя лицензию до конца 2025 года, сошлётся на этот пост, тому я вышлю в библиотеку компании книги со своей подписью и другие сувениры :)

Заметка о том, что мы тоже допускаем ошибки. Никто не совершенен.

if (Workbench.versionInfo.version >= '1.44.0') {

А ещё в статье можно найти пасхалку, вернее намёк на вектор развития PVS-Studio 😉

ФСТЭК сообщила о введении требований для подрядчиков с доступом к IT-инфраструктуре КИИ

19 ноября. / D-Russia /. В 2026 году ожидается принятие ряда нормативных правовых актов, в которых, в частности, будет прописано выполнение подрядчиками требований, предъявляемых к владельцам значимых объектов критической информационной инфраструктуры (ЗО КИИ), сообщила начальник управления Федеральной службы по техническому и экспортному контролю (ФСТЭК) Елена Торбенко на SOC-Форуме во вторник, пишет «Интерфакс».

Таким образом, на подрядчиков распространятся нормы 187-ФЗ «О безопасности КИИ».

Ранее эксперт рассказывал D-Russia.ru, что распространение требований на подрядные организации уже предусмотрено приказом ФСТЭК, который вступит в силу с марта 2026.

Всего было выявлено более 1,1 тысячи нарушений в обеспечении безопасности объектов КИИ (период не уточняется – ред.), по словам Торбенко. 98% нарушений традиционно связаны с несоответствием фактического состава ЗО КИИ сведениям, включенным в реестр таких объектов, сказала Торбенко.

Также к типовым нарушениям она отнесла отсутствие контроля за действиями подрядчиков, имеющих доступ к IT-инфраструктуре ЗО КИИ.

Особо Торбенко отметила невыполнение владельцами ЗО КИИ требований указа президента №250, запрещающего использование на ЗО КИИ средств защиты информации производства компаний из недружественных стран. Этот указ был принят в 2022 году, а срок его исполнения наступил 1 января 2025 года.

«С момента принятия указа прошло 3,5 года, и было достаточно времени, чтобы решить, как его выполнить, – сказала Торбенко. – В течение года не штрафовали за неисполнение этого указа, теперь органы прокуратуры указали, что мы поступали неправильно. Поэтому владельцам ЗО КИИ необходимо спланировать в ближайшее время исполнение указа №250».

В дальнейшем, по её словам, за такое нарушение будут возбуждать административные дела.

Запись вебинара «Особенности разработки встроенного ПО по требованиям ФБ»

Вместе с экспертами из ФанкСэйфети разбирались с такими сущностями, как ГОСТ Р МЭК 61508, уровнями SIL, стандартом MISRA C, сертификацией по функциональной безопасности и т.д.

В конце была активная дискуссия ответов на вопросы. По её итогу хочется привести некоторую дополнительную информацию и ссылки.

1) Говоря про безопасные и сертифицированные компиляторы, стоит отметить, что в 2024 году появился ГОСТ Р 71206-2024: "Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования". Также см. пост из цикла разбора РБПО: Процесс 12 — Использование безопасной системы сборки программного обеспечения и вебинар на эту тему.

2) Инструменты SAST и DAST не обязаны быть сертифицированы. Из методической рекомендация ФСТЭК № 2025-07-011 | Уровень критичности: 3

Область: Инструментальный анализ

Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.

Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования: ...

См. также выдержку из эфира AM Live "Разработка безопасного программного обеспечения (РБПО)". Анализатор PVS-Studio сейчас участвует в инициативе ФСТЭК по испытаниям статических анализаторов кода, но это другая история.

3) Был вопрос, связанный с объединением требований ФБ и ИБ в одном стандарте. Некоторые усилия в этом направлении предпринимаются, см. примеры ГОСТов ниже:

ГОСТ Р 59506-2021/IEC TR 63074:2019. Национальный стандарт Российской Федерации. Безопасность машин. Вопросы защиты информации в системах управления, связанных с обеспечением функциональной безопасности.

ГОСТ Р 71452— 2024/ IEC/PAS 63325:2020. Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла.

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

Познавательная техническая заметка про PVS-Studio.

Продукт уже настолько большой и комплексный, что приходится время от времени подсвечивать (описывать) его отдельные части. В противном случае, новые пользователи могут не подозревать о наличии различных полезных возможностей.

Ой, забыл написать, что выложена запись 19-го вебинара про нефункциональное тестирование из серии «Вокруг РБПО». И уже завтра (26.11.2025) в 16:00 по МСК пройдёт очередная онлайн встреча «Процесс 20. Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения». Подключайтесь.

P.S. Про 19 процесс РБПО. Сложно выявлять уязвимые сценарии взаимодействия с системой для их предотвращения, не имя представление о чём в целом речь. Поэтому приведу несколько ссылок, от чего можно оттолкнуться. Ссылки точно не претендует на полноту картины, но хотя бы подскажут с чего начать изучение темы нефункционального тестирования:

1. Server-Side Request Forgery (SSRF).
2. Межсайтовый скриптинг (XSS).
3. XEE-атака (billion laughs attack).
4. XXE-атака (XML External Entity).
5. Path Traversal.
6. ReDoS (Regular expression Denial of Service).
7. Уязвимость XSS в приложении ASP.NET: разбираем CVE-2023-24322 в CMS mojoPortal.
8. Обработка XML-файлов как причина появления уязвимостей.

Мы всё про ГОСТы и про ГОСТы... Для разнообразия рассмотрели в статье Cyber Resilience Act.

Cyber Resilience Act (CRA) — это нормативно-правовой акт (или же закон), который предъявляет требования к производителям ПО, выпускающим свои продукты на рынок стран Евросоюза. Требования касаются кибербезопасности разрабатываемого продукта.

Создание закона было инициировано Европейской комиссией. Он вступил в силу 10 декабря 2024 года, а его основным требованиям необходимо начать соответствовать через 36 месяцев с момента вступления в силу, т.е. с 11 декабря 2027 года. Но в нём есть положения, у которых более ранние сроки соответствия.

Продолжаем погружаться тематику разработки игр. Я буду на разогреве. Расскажу, как мы написали свой собственный класс строки, а потом удалили его.

Коллега сейчас обнаружил забавный факт, который идёт в копилку "PVS-Studio - двигатель прогресса".

Слышали ли вы про то, что злобные C и C++ компиляторы могут удалить вызов memset в конце функции во время оптимизаций? У нас даже про это диагностика есть, V597.

Проблема насущная и для её решения в стандарт C23 внесли новую функцию memset_explicit, которая теперь обязательна для реализации в стандартной библиотеке вместо memset_s. Так вот, автор предложения (Miguel Ojeda, P1315) в своём документе сослался на нашу диагностику (ссылка №3). И похоже, что он давно про нас знает, т.к. умудрился вставить ссылку ещё аж на старый сайт viva64.

Не зря столько лет говорим про memset. Приятно, что нас уже в проползалы затаскивают :)

Стоматологические услуги для компиляторов на примере LLVM 21

Прям мини детектив о появлении различных багов :) Рекомендую погрузиться.

И хорошая демонстрация, что статический анализатор PVS-Studio полезен даже самым опытным разработчикам.