Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
В заметке собраны ответы на вопросы, которые часто задают нам после прочтения наших статей.
Да. Мы стараемся информировать разработчиков о том, что мы нашли с помощью PVS-Studio в их проекте ряд ошибок. Как правило, мы отправляем им письмо со ссылкой на статью или пишем в баг-трекер. Также, мы предлагаем на некоторое время регистрационный ключ, чтобы поработать с PVS-Studio и изучить диагностические сообщения, про которые мы не написали в статье.
Почему "стараемся", а не "точно уведомляем"? Изредка наши письма попадают в спам, а сообщения из баг-трекера удаляются, так как содержат ссылки и тоже воспринимаются как спам. Жаль, но что делать.
Да. Как только появилась такая возможность, мы начали запускать ночные тесты, в которых анализатор проверяет сам себя и на почту присылается отчет.
Мы не вели учёт интересных ошибок, которые обнаруживал PVS-Studio в самом себе. Поэтому, к сожалению, написать статью "Проверяем PVS-Studio с помощью PVS-Studio" не представляется возможным. Вдобавок, уже давно на почту не приходит сообщений о найденных ошибках. Дело в том, что мы используем инкрементальный анализ и замеченные ошибки исправляются ещё до того, как код попадают в систему контроля версий.
Если интересно узнать больше, то предлагаем познакомиться со статьей "Как мы тестируем анализатор кода".
Это дорого и сложно. Когда-нибудь Linux-версия, возможно, появится, но в ближайших планах этого нет. Пока мы не видим смысла вкладывать большое количество ресурсов в направление, где будет сложно заработать на продажах.
Убеждение, что в Linux-мире трудно зарабатывать происходит из личного опыта участия в одном проекте. Есть и косвенные подтверждения. Например, версия AQtime Linux edition более не разрабатывается и не поддерживается. Это значит, что зарабатывать на инструментах для программирования в Linux мире крайне сложно.
Технически перенести код PVS-Studio.exe на другую платформу можно, так как никаких Windows-specific функции там почти не используются.
Для того чтобы сделать PVS-Studio для другой операционной системы нужно уметь обеспечить на той платформе уровень качества не ниже, чем на Windows-платформе. Для обеспечения уровня качества PVS-Studio мы используем много различных типов тестов: статический анализ, юнит-тесты, функциональные тесты, тесты UI и так далее. Убедиться в том, что на другой платформе анализатор ведет себя точно также как и на Windows, можно только пройдя все эти тесты. Тестирование анализатора составляет около 30% от общей цены разработки.
Кроме того следует учитывать, что файлы с кодом, обрабатываемые компилятором Visual C++, содержат определенные специфичные для данного компилятора конструкции. И PVS-Studio их поддерживает. В других компиляторах (например, GCC) есть также специфичные конструкции, которые надо будет поддержать. Это незаметный, но очень большой объем работ. То, что ключевое слово '__restrict' используется в 10 000 раз реже, чем 'for' вовсе не означает, что его можно не поддерживать. Многие программисты и не подозревают о таких вещах как __w64, __noop, __if_exists, __int3264, __uuidof, __based, __LPREFIX и так далее и так далее.
Наконец используемые наборы заголовочных (include) файлов в разных системах также различаются. И если PVS-Studio работает с заголовочными файлами Visual C++, то это совершенно не значит, что также все будет работать с заголовочными файлами GCC.
Это не ограничение PVS-Studio. Никакая версия Visual Studio Express Edition не поддерживает подключаемые модули расширений - это ограничение данной редакции Visual Studio. Интегрироваться с Visual Studio Express Edition невозможно.
Ничего.
PVS-Studio это сокращенное название нашей компании "Program Verification Systems" и слово "Studio".
PVS это Prototype Verification System.
То, что там и там есть "PVS" - простое случайное совпадение.
PVS-Studio стоит адекватную сумму. Тот, кто приобретает PVS-Studio, как правило, не поднимает вопрос о цене и скидках, так как инструмент им нужен. Тем, кто говорят о высокой цене, инструмент PVS-Studio не нужен. Поэтому для них, какова бы не была цена, она всё равно будет слишком высокой.
Мы проверили это экспериментально. Нам часто пишут о слишком высокой цене и говорят, что такой инструмент правильнее будет продавать по $100-$200. Мы начали предлагать этим людям купить PVS-Studio по названной ими цене ($100-$200). Почти никто не купил. Вывод: это праздношатающиеся комментаторы, которых не интересует качество своего кода и которым PVS-Studio просто не нужен.
Очень дорого стоит поддержка. Ответить на вопросы могут только непосредственно разработчики статического анализатора. У нас нет вопросов в духе "как мне скачать файл?" или "что такое тип float?". Наши клиенты это программисты, которые задают сложные вопросы по языку Си++ или отписывают ошибки, сопровождаемые распечаткой стека при падении. Обрабатывать такие запросы могут только программисты.
Это может быть по двум причинам:
1) Вы уже исправили ошибки, которые смог бы найти PVS-Studio, другими методами тестирования. И сделали это намного дороже, чем если бы использовали PVS-Studio. Подробнее эта тема раскрыта в следующих статьях:
2) Вам попадаются ложные срабатывания, и ваше внимание быстро ослабляется. Как результат, вы не замечаете настоящих ошибок. Это большая беда, с которой мы пока не знаем, что делать. Очень показательна в этом плане вот эта дискуссия, возникшая на сайте reddit.com.
Человек читает в статье вот этот текст:
Fragment N1.
Diagnostic message V511.
The sizeof() operator returns size of the pointer, and not of the array, in 'sizeof(src)' expression.
ID_INLINE mat3_t::mat3_t( float src[ 3 ][ 3 ] ) {
memcpy( mat, src, sizeof( src ) );
}
Correct code:
memcpy( mat, src, sizeof(float) * 3 * 3);И пишет, что мы не правы и ошибки нет:
Fragment N1.
Except it doesn't. The sizeof() operator returns the size of the object, and src is not a pointer - it is a float[3][3]. sizeof() correctly returns 36 on my machine.
Мы подробно объясняем, в чем он не прав. После чего он удивляется и говорит спасибо:
Oop - yup - I essentially tested with with "char A[100];" rather than "void Foo(char B[100])"
Оказывает, он даже сделал тестовый пример, чтобы проверить. Но написал его неправильно. Представляете, человек уделил время анализу ошибки, написал тест, и всё равно не разобрался!
Кстати, про это жалуются и в замечательной статье "A Few Billion Lines of Code Later - Using Static Analysis to Find Bugs in the Real World". Смысл в следующем. Если первые 10 сообщений, которые изучил программист, оказались ложными, то он и ко всем остальным начинает относиться как к ложным.
Кстати, вышесказанное ещё раз подтверждает важность поддержки клиентов и что это очень дорогое занятие.
0
0
0
0