bool isclosebrace (TCHAR c)
{
return c == _T ('}') ||
c == _T ('}') || // должно быть ')'
c == _T (']') ||
c == _T ('>');
}
Посоветуйте интересные проверки для анализа Си/Си++ кода
здесь. Мы постоянно реализуем новые диагностические правила. Список того, что ещё можно реализовать, кажется мне бесконечным. Мы постоянно пополняем todo-лист новыми примерами ошибок, которые хорошо-бы научиться диагностировать. Так что с проблемы с нехваткой задач у нас нет. Зато есть проблема, как выбрать наиболее интересные и распространенные типы ошибок. Логично, в первую очередь реализовывать диагностику тех ошибок, которые наиболее часто встречаются в программах. Вопрос в том, как расставить приоритеты разным задачам.
Была предложена идея, создать на сайте раздел, где будут перечислены различные примеры дефектов и пользователи смогут проголосовать за те ошибки, которые на их взгляд они чаще всего допускают. Мне этот подход не нравится по двум веским причинам.
1) Список ошибок будет очень большой. Это значит, что никто не будет просматривать его целиком. Приоритет получат примеры, расположенные в начале списка. Можно конечно сортировать примеры случайным образом, но тогда не понятно, как продолжить просмотр списка, например на следующий день. И вообще всё становится излишне сложно.
2) Программисты недооценивают простые ошибки (см. миф второй). Например, они не любят признавать, что огромную часть ошибок возникает из-за Copy-Paste и опечаток. Мало кто будет голосовать, за подобный пример:
Программисты будут голосовать за неинициализированные переменные, выход за границы массивов и другие интересные случаи. Но как показывает наш опыт, огромное количество ошибок, это опечатки различных видов. Таким образом, голосование не будет отображать реальную картину.
Я придумал другой вариант, как расставить приоритеты. Я прошу вас, уважаемые программисты, привести промеры ошибок, которые вы допускали лично. Пишите про любые ошибки, не важно, кажутся они вам серьезными, или нет. Приведённые примеры будут живыми и будут отражать действительную картину. Я надеюсь, что можно будет увидеть, какие проблемы встречаются наиболее часто.
Я сделаю несколько таких обсуждений на разных сайтах. Паттерны ошибок, которые есть в нашей базе и про которые кто-то расскажет, получат больший приоритет. Если один и тот же тип ошибки будет описан несколько раз, значит этим вообще стоит заняться в первую очередь. Мы будем очень благодарны за ваши примеры.
Приведу пару примеров кода, который было бы интересно увидеть.
Хотели проверить, что строка пустая, но забыли разменивать указатель. Достаточно распространенная опечатка. Корректный вариант: "if (*headerM != '\0')".
Не там поставлена закрывающаяся скобка. В результате функция memcmp() сравнивает 0 байт.
Лишний раз объявили переменную 'ret'. В результате, не будет обработан случай, когда не удастся сохранить файл.
Приведенные примеры не требуют сложного AI и как следствие хорошо диагностируется инструментами статического анализа. Хочется увидеть что-то в таком духе.
Я думаю, многие примеры, которые будут приведены, уже диагностируются PVS-Studio. Но это не страшно, я их отфильтрую. Если хотите, Вы сами можете попробовать, сможет ли PVS-Studio найти тот или иной тип ошибки. Для этого можно воспользоваться демонстрационной версией. Кстати, она полностью функциональна и позволит заодно попробовать проверить ваши проекты.
---
С уважением, Андрей Карпов
Лучше всего комментарии оставлять здесь, или написать мне на электронную почту: karpov[@]viva64.com
Я один из разработчиков анализатора PVS-Studio. Подробнее про анализатор можно почитать
Была предложена идея, создать на сайте раздел, где будут перечислены различные примеры дефектов и пользователи смогут проголосовать за те ошибки, которые на их взгляд они чаще всего допускают. Мне этот подход не нравится по двум веским причинам.
1) Список ошибок будет очень большой. Это значит, что никто не будет просматривать его целиком. Приоритет получат примеры, расположенные в начале списка. Можно конечно сортировать примеры случайным образом, но тогда не понятно, как продолжить просмотр списка, например на следующий день. И вообще всё становится излишне сложно.
2) Программисты недооценивают простые ошибки (см. миф второй). Например, они не любят признавать, что огромную часть ошибок возникает из-за Copy-Paste и опечаток. Мало кто будет голосовать, за подобный пример:
Код:
Я придумал другой вариант, как расставить приоритеты. Я прошу вас, уважаемые программисты, привести промеры ошибок, которые вы допускали лично. Пишите про любые ошибки, не важно, кажутся они вам серьезными, или нет. Приведённые примеры будут живыми и будут отражать действительную картину. Я надеюсь, что можно будет увидеть, какие проблемы встречаются наиболее часто.
Я сделаю несколько таких обсуждений на разных сайтах. Паттерны ошибок, которые есть в нашей базе и про которые кто-то расскажет, получат больший приоритет. Если один и тот же тип ошибки будет описан несколько раз, значит этим вообще стоит заняться в первую очередь. Мы будем очень благодарны за ваши примеры.
Приведу пару примеров кода, который было бы интересно увидеть.
Код:
TCHAR headerM[headerSize] = TEXT("");
...
if (headerM != '\0')
...
if (headerM != '\0')
Код:
if (memcmp(this, &other, sizeof(Matrix4) == 0)) {
Код:
BOOL ret = TRUE;
if (m_hbitmap)
BOOL ret = picture.SaveToFile(fptr);
if (m_hbitmap)
BOOL ret = picture.SaveToFile(fptr);
Приведенные примеры не требуют сложного AI и как следствие хорошо диагностируется инструментами статического анализа. Хочется увидеть что-то в таком духе.
Я думаю, многие примеры, которые будут приведены, уже диагностируются PVS-Studio. Но это не страшно, я их отфильтрую. Если хотите, Вы сами можете попробовать, сможет ли PVS-Studio найти тот или иной тип ошибки. Для этого можно воспользоваться демонстрационной версией. Кстати, она полностью функциональна и позволит заодно попробовать проверить ваши проекты.
---
С уважением, Андрей Карпов
Лучше всего комментарии оставлять здесь, или написать мне на электронную почту: karpov[@]viva64.com
Получение указателя на ф-цию из библиотеки, закрытие библиотеки и обращение к ф-ции (уже недоступной) через указатель.
Цитата: sadovoya
Получение указателя на ф-цию из библиотеки, закрытие библиотеки и обращение к ф-ции (уже недоступной) через указатель.
Спасибо. Но к сожалению, это пожалуй слишком высокоуровневые действия для статического анализатора.
сюда.
Здесь дискуссия как-то совсем не идёт. Если интересно - предлагаю переместиться