Качество анализа кода сообщества Visual Studio с помощью аннотаций SAL
Я надеюсь, что этот вопрос не выходит за рамки SO; если это так (извините в этом случае), пожалуйста, скажите мне, где оно находится, и я постараюсь переместить его туда.
Концепция чего-либо SAL аннотации для статического анализа кода в C / C ++ мне кажется действительно полезным. Взять, к примеру, неправильно выполненную wmemcpy пример на MSDN: Понимание SAL:
wchar_t * wmemcpy(
_Out_writes_all_(count) wchar_t *dest,
_In_reads_(count) const wchar_t *src,
size_t count)
{
size_t i;
for (i = 0; i <= count; i++) { // BUG: off-by-one error
dest[i] = src[i];
}
return dest;
}
MSDN говорит, что «инструмент анализа кода может выявить ошибку, анализируя только эту функцию», Это кажется великолепным, но проблема в том, что когда я вставляю этот код в VS 2017 Community, при анализе кода не появляется никаких предупреждений об этом, даже если включены все предупреждения анализа. (Другие предупреждения, такие как C26481 Don't use pointer arithmetic. Use span instead (bounds.1). делать.)
Еще один пример, который должен выдавать предупреждения (по крайней мере, в соответствии с ответ на Какова цель SAL (исходный язык аннотации) и в чем разница между SAL 1 и 2?), но не
_Success_(return) bool GetASmallInt(_Out_range_(0, 10) int& an_int);
//main:
int result;
const auto ret = GetASmallInt(result);
std::cout << result;
И случай неправильного предупреждения:
struct MyStruct { int *a; };
void RetrieveMyStruct(_Out_ MyStruct *result) {
result->a = new int(42);
}
//main:
MyStruct s;
RetrieveMyStruct(&s);
// C26486 Don't pass a pointer that may be invalid to a function. Parameter 1 's.a' in call to 'RetrieveMyStruct' may be invalid (lifetime.1).
// Don't pass a pointer that may be invalid to a function. The parameter in a call may be invalid (lifetime.1).
result явно помечен _Out_ и не _In_ или же _Inout_ так что это предупреждение не имеет смысла в этом случае.
У меня такой вопрос: почему анализ кода на основе SAL в Visual Studio кажется довольно плохим; я что-то пропустил? Visual Studio Professional или Enterprise может быть лучше в этом аспекте? Или есть инструмент, который может сделать это лучше?
И если это действительно очень плохо: это известная проблема и есть ли планы улучшить этот тип анализа?
Связанные с: Visual Studio 2013 статический анализ кода — насколько он надежен?
Решение
Функции контрактов, из которых аннотации SAL — легкая реализация, сделай это возможным локально рассуждать о том, что функция делает правильные вещи и используется неправильно, или наоборот. Без них вы могли бы обсуждать понятие ошибки только в контексте всей программы. С ними, как говорится в документации, становится возможным локально сказать, что поведение функции является ошибкой, и вы можете надеяться, что инструмент статического анализа найдет ее.
Механическая проверка того, что часть кода не имеет ошибок, остается трудной проблемой даже с этой помощью. Существуют разные методы, потому что существуют различные частичные подходы к проблеме. Все они имеют свои сильные и слабые стороны, и все они содержат много эвристики. Циклы являются частью того, что затрудняет прогнозирование всех поведений программы, и разработчики этих инструментов могут предпочесть не жестко кодировать шаблоны для чрезвычайно простых циклов, поскольку эти шаблоны редко бывают полезными на практике.
И если это действительно очень плохо: это известная проблема и есть ли планы улучшить этот тип анализа?
Да, исследователи работали над этой темой в течение десятилетий и продолжают совершенствовать теорию и переносить теоретические идеи в практические инструменты. Как пользователь, у вас есть выбор:
- если ты необходимость Ваш код не содержит ошибок, например, потому что он предназначен для критического контекста безопасности, тогда у вас уже есть очень сложная методология, основанная на интенсивном тестировании на каждом уровне V-цикла, и этот вид статического анализа может уже поможет вам достичь того же уровня уверенности с меньшими (но некоторыми) усилиями. Для этой цели вам понадобится более выразительные спецификации контракта, чем аннотации SAL. Примером является ACSL для C.
- Если вы не готовы приложить значительные усилия, чтобы гарантировать отсутствие ошибок в коде с высокой степенью достоверности, вы все равно можете воспользоваться преимуществами такого статического анализа, но в этом случае рассматривайте любую найденную ошибку как бонус. Аннотации, поскольку они имеют формально определенное значение, также могут быть полезны для определения вины даже в контексте ручного анализа кода, в котором не используется статический анализатор. Аннотации SAL были разработаны специально для этого варианта использования.
Другие решения
Других решений пока нет …