На текущий момент таких планов нет, но никто не знает, как может сложиться судьба дальше. Например, у нас недавно был внутренний хакатон, и на нем мы писали прототип анализатора для языка Lua. Кстати, скоро опубликуем про это статью :)
Насчёт требования по отсутствию STL не знал, спасибо. Однако у них она все же используется, если сделать поиск в коде по std:: можно найти кое-что. По поводу же данного исправления, опять таки это лишь вариант исправления в общем случае. Кажется, они уже исправляли похожую проблему. По поиску можно найти, например, такой вариант.
Можно воспользоваться std::ptrdiff_t (или аналогом, если не хочется использовать стандартную библиотеку) вместо int64_t. Подобрать полностью подходящий вариант исправления могут только сами разработчики, так как они знают все тонкости проекта. Я лишь предложил варианты исправления в общем случае, а дальше нужно смотреть, что подойдет лучше. Я, кстати, создал issue у них на github, и они отписали уже по всем фрагментам.
Да, например, есть такая статья. А так мы регулярно проверяем сами себя во время ночных сборок на сервере, и разработчикам приходят уведомления на почту, если есть срабатывания.
Так, а минусы будут? :D Блог компании PVS-Studio бесплатно находит и расписывает чужие ошибки, предлагая исправленные варианты кода. Как минимум это экономит время и силы разработчиков на поиск и исправление, как максимум обучает других не совершать подобные ошибки в своём коде :)
Сложно. Для этого надо, чтобы все наши анализаторы работали через одно обобщенное внутреннее представление в виде AST (Abstract Syntax Tree). Тогда можно будет запустить какой-то общий набор диагностических правил.
Для каждого языка программирования строятся различные AST, которые учитывают его семантику. К сожалению, обобщить все многообразие AST для целей статического анализа так легко не получится – будет утерян контекст исходного кода.
Я бы сказал всё зависит от области применения. В тех областях, где производительность и эффективность не на первом месте, высокоуровневые языки позволяют сэкономить время программиста, упрощая ему жизнь. Для бизнеса это может оказаться выгоднее, чем писать компактный и эффективный код (надо отметить, что высокоуровневый язык != некомпактный и неэффективный код, зачастую наоборот (например, если речь про C++)). Но всё должно быть в меру и описанная вами ситуация, к сожалению, не редкость и действительно пугает.
Насколько мне известно, допустимы оба варианта написания, в данном случае для акцентирования внимания на выполнении деления по модулю использован вариант с предлогом "by".
Да, вы правы, оригинальный DOOM 1993 года был написан на C, но к счастью (или к сожалению) время не стоит на месте, и люди портируют старые игры, используя более высокоуровневые языки.
Всегда пожалуйста! Это Вам спасибо за Ваши труды. Я всё же рекомендую, если дойдут руки, самим провести анализ и разобрать срабатывания, т.к. в статье описаны далеко не все случаи. Также, если времени разбираться со всеми срабатываниями пока нет, можно подавить существующие и разбирать только относящиеся к новому коду, а к старым возвращаться по возможности.
А вот и обещанная статья.
На текущий момент таких планов нет, но никто не знает, как может сложиться судьба дальше. Например, у нас недавно был внутренний хакатон, и на нем мы писали прототип анализатора для языка Lua. Кстати, скоро опубликуем про это статью :)
Насчёт требования по отсутствию STL не знал, спасибо. Однако у них она все же используется, если сделать поиск в коде по std:: можно найти кое-что. По поводу же данного исправления, опять таки это лишь вариант исправления в общем случае. Кажется, они уже исправляли похожую проблему. По поиску можно найти, например, такой вариант.
Можно воспользоваться std::ptrdiff_t (или аналогом, если не хочется использовать стандартную библиотеку) вместо int64_t. Подобрать полностью подходящий вариант исправления могут только сами разработчики, так как они знают все тонкости проекта. Я лишь предложил варианты исправления в общем случае, а дальше нужно смотреть, что подойдет лучше.
Я, кстати, создал issue у них на github, и они отписали уже по всем фрагментам.
Да, ссылка. Там их уже, кстати, немало от нас :D
Да, например, есть такая статья. А так мы регулярно проверяем сами себя во время ночных сборок на сервере, и разработчикам приходят уведомления на почту, если есть срабатывания.
Так, а минусы будут? :D
Блог компании PVS-Studio бесплатно находит и расписывает чужие ошибки, предлагая исправленные варианты кода. Как минимум это экономит время и силы разработчиков на поиск и исправление, как максимум обучает других не совершать подобные ошибки в своём коде :)
Спасибо за интересный вопрос.
Сложно. Для этого надо, чтобы все наши анализаторы работали через одно обобщенное внутреннее представление в виде AST (Abstract Syntax Tree). Тогда можно будет запустить какой-то общий набор диагностических правил.
Для каждого языка программирования строятся различные AST, которые учитывают его семантику. К сожалению, обобщить все многообразие AST для целей статического анализа так легко не получится – будет утерян контекст исходного кода.
В начале статьи есть упоминание и ссылка на его проверку.
Справедливое замечание с учётом характера статьи :D
Я бы сказал всё зависит от области применения. В тех областях, где производительность и эффективность не на первом месте, высокоуровневые языки позволяют сэкономить время программиста, упрощая ему жизнь. Для бизнеса это может оказаться выгоднее, чем писать компактный и эффективный код (надо отметить, что высокоуровневый язык != некомпактный и неэффективный код, зачастую наоборот (например, если речь про C++)). Но всё должно быть в меру и описанная вами ситуация, к сожалению, не редкость и действительно пугает.
Насколько мне известно, допустимы оба варианта написания, в данном случае для акцентирования внимания на выполнении деления по модулю использован вариант с предлогом "by".
Согласен, выглядит жутко :D. Даже с подсказкой анализатора мне понадобилось определённое количество времени, чтобы разобраться, что там происходит.
Да, вы правы, оригинальный DOOM 1993 года был написан на C, но к счастью (или к сожалению) время не стоит на месте, и люди портируют старые игры, используя более высокоуровневые языки.
Всегда пожалуйста! Это Вам спасибо за Ваши труды.
Я всё же рекомендую, если дойдут руки, самим провести анализ и разобрать срабатывания, т.к. в статье описаны далеко не все случаи. Также, если времени разбираться со всеми срабатываниями пока нет, можно подавить существующие и разбирать только относящиеся к новому коду, а к старым возвращаться по возможности.