Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

Логично. Теперь объект разрушается, когда завершается его область видимости, ограниченная фигурными скобками.Только это имеет перпендикулярное отношение к рассматриваемой теме. Внимательно читаем описание функции alloca. Самое важное:

Выделенная с использованием alloca память автоматически освобождается при выходе из фун­кции, которая вызвала alloca.

Учимся рефакторить код на примере багов в TDengine, часть 2: макрос, пожирающий стек

Потому, что встраивание функции не означает, что это тоже самое, что подстановка макроса. Должны быть выполнены все те-же самые действия, что и при вызове функции.

Функции и макросы по-разному работают. Поясняющий пример:

#include <iostream>

struct A
{
    A() { std::cout << "A()" << std::endl; }
    ~A() { std::cout << "~A()" << std::endl; }
};

#define MACROS A a;

void Function()
{
    A a;
}

void UseMacros()
{
    std::cout << "Используем макрос" << std::endl;
    MACROS
    std::cout << "Конец использования макроса" << std::endl;
}

void UseFunction()
{
    std::cout << "Используем функцию" << std::endl;
    Function();
    std::cout << "Конец использования функции" << std::endl;
}


int main() {
    UseMacros();
    std::cout << "----------------" << std::endl;
    UseFunction();
    return 0;
}

Распечатает:

Используем макрос
A()
Конец использования макроса
~A()
----------------
Используем функцию
A()
~A()
Конец использования функции

Учимся рефакторить код на примере багов в TDengine, часть 1: про колбасу

Хотя, наверное, неважной, если до сих пор не было замечено

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

Обходим BitLocker и вытягиваем из памяти ключи в Windows 11

Очень может быть :) Ссылка для тех, кто не знает, про что речь :) Этого очень много везде.

Undefined behavior ближе, чем вы думаете

Путеводитель C++ программиста по неопределённому поведению: часть 2 из 11.

Путеводитель C++ программиста по неопределённому поведению

Приглашаем на вебинар "C++ и неопределённое поведение" 27 февраля 2025 в 14:00.

Хотя, скорее всего, это будет формат подкаста". Мы пригласили в гости Дмитрия Свиридкина — автора книги "Путеводитель C++ программиста по неопределённому поведению". Обсудим грани, отделяющие корректный C++ код от некорректного, попросим рассказать историю написания книги, поговорим о развитии языка и его будущем.

Путеводитель C++ программиста по неопределённому поведению

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

Дарим электронную версию книги «Вредные советы для С++ программистов»

Мм.. нет )

60 антипаттернов для С++ программиста, часть 12 (совет 56 — 60)

Для любителей длинных текстов - "Путеводитель C++ программиста по неопределённому поведению" в 12 частях :)

Главный вопрос программирования, рефакторинга и всего такого

Для любителей длинных текстов - "Путеводитель C++ программиста по неопределённому поведению" в 12 частях :)

Путеводитель C++ программиста по неопределённому поведению

Если открыть первую часть, то можно прочитать :)

Так что, встретив путеводитель Дмитрия Свиридкина по UB на GitHub (ubbook), я с большим любопытством с ним ознакомился. Выписал для себя ряд интересных мыслей, которые со временем станут основой новых диагностических правил. В общем, я получил от чтения и удовольствие, и пользу.

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

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

В общем, перед вами переработанная и расширенная ubbook.

Плюс перевод на английский.

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Да. Я про него и подумал :)

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Многословно слишком, NaN какой-то приплетён... Кстати, ради интереса напиши, что если попробовать как-то так сделать:

#define INT static int
#include <iostream>
void foo(int& value)
{
    value *= value;
}
int main()
{
    INT a;
    foo(a);
    std::cout << a;
    return 0;
}

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Кстати, с синтетическими тестами надо быть аккуратными :) Помню была у меня одна старая заметка: Почему я не люблю синтетические тесты. :)

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Видел аналогичный вопрос на stackoverflow про Cppcheck (название топика: Why are pointers difficult for static analysis even in simple cases). И пример там схожий был и Cppcheck аналогично баг не находил. Сейчас топик удалён. Не Вы случаем были? :)

А ответ, это не совсем простой пример, как может казаться со стороны. Знаем про такое, будем со временем дорабатывать.

Новые диагностические правила в PVS-Studio 7.34

И есть Бесплатная лицензия PVS-Studio для Open Source.

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Над этим начинанием пока не работаем, так как собственно как я понимаю совсем недавно прозвучало в анонсах задач ФСТЭК на 2025-2030 год. Я думаю, имеется в виду доклад от ФСТЭК про совершенствование безопасности системного ПО, где говорилось про "развитие набора квалифицированных тестов для инструментов жизненного цикла безопасного ПО". Примем мы какое-то участие во всём этом пока не понятно. Мы просто не знаем, как и что будет.

Другое дело, что мы уже поработали и продолжим работу над лучшим соответствием критерием, изложенным в ГОСТ. Добавим новые детекторы для выявления критических ошибок, можно поработать над анализом косвенных вызовов и так далее.

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

ГОСТ на болты

... ГОСТируют только вещи планируемые к регулировке со стороны государства - зачем регулировать разработку подобной штуки? Затем чтобы применять ее в госсекторе. Как применять ее в госсекторе? Наверное навязывать всем разработчикам задействованным в госсекторе и выполняющим госзаказы...

А я думал, чтобы болты с гайками сходились :)

Прочитай ГОСТ :) Там совершенно адекватные вещи про улучшение процессор разработки ПО. Если не понятна актуальность, что могло быть не так со статическим анализом, то некоторые моменты я здесь разбирал.

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Это не так работает. Сейчас в целом идёт тренд на стандартизацию и регулирование процессов безопасной разработки ПО. ГОСТ про статический анализ – это небольшая часть этого процесса. Будут вводиться новые требования и стандарты. Например, буквально вчера 20.12.2024 введён в действие обновлённая версия ГОСТ Р 56939-2024 – Защита информации. Разработка безопасного программного обеспечения. Общие требования.

PVS-Studio соответствует требованиям ГОСТ Р 71207—2024 (статический анализ программного обеспечения)

Гм.. Раз была лицензия в конторе, так быть может основные ошибки уже были исправлены? :) Ну или вариант, код уже был качественным, что тоже бывает.