Для gcc можно использовать target атрибуты. И не надо ни каких флагов компиляции.
Но могут быть проблемы с LTO, если использовать одно имя функции с разными реализациями и атрибутами target.
Без lto, должно быть все хорошо. Либо можно обойти проблему использую функции с уникальными именами и собственную реализацию выбора функции на основе поддержки разных видов simd (я пока такое не делал)
Пример в wiki: https://gcc.gnu.org/wiki/FunctionMultiVersioning
Из недостатков, clang такое не поддерживает и надо обкладывать все через #ifdef/#define
современный, думаю имеется в виду, которому меньше 10 или 20 лет после релиза. На пример вот gcc 4.4 http://melpon.org/wandbox/permlink/UHC7Ee0wWxncUxOx находит проблему
Я писал про тесты а не про анализатор.
Тесты в этом репозитории только для простых случаев. А ваш анализатор не только для простых.
Gcc также может многое, что могли бы находить анализаторы, на пример ошибки форматной строки, такие как переполнение буфера назначения. Или забытые скобочки, на основе анализа форматирования кода…
Я не противопоставляю gcc и pvs studio. Просто разработчики редко даже включают и проверяют предупреждения компилятора, не то что использует статические анализаторы. Если бы все исправляли все предупреждения компилятора, то и вы бы находили меньше проблем :)
Зачем тестировать то, что может находить компилятор? А сложных опечаток в тестах возможно нет потому, что тесты проверяют совсем простые случаи.
А про nulll pointer, возможно вам стоит добавить еще один уровень предупреждений, которые по вашему мнению не интересны пользователям, но находят проблемы.
clang не может корректно переварить исходники для gcc. Я имею в виду встроенное построение дерева.
Часть расширений он просто игнорирует, на пример некоторые атрибуты.
Debian пока еще поддерживает более одного типа init'а. Хотя systemd поумолчанию.
Если писать скрипты для каждого инита, это будет слишком много. Видимо поэтому маинтейнеры выбирают те скрипты, которые везде будут работать.
К сожалению, такая система уже есть, и почти захватила все дистрибутивы GNU/Linux :(
Хоть она и не от Линуса, но специально для линукс ядра.
Это называется SystemD. Сейчас это почти дистрибутив, за исключением загрузчика и графической части и да пока еще без сишной библиотеки.
Немного спорное утверждение, что одиночкам статический анализ не нужен.
В одном из проектов, где я участвую, для статического анализа используются почти все версии gcc и clang (да да они тоже многое могут найти с нужными флагами), различные cppcheck и множество других утилит и сервисов и не только статического анализа кода как такового но и стиля. В сожалению для вас, все это распространяется бесплатно. И хоть статический анализ и используется, но нет платных инструментов.
Pvs-studio тоже используется, но не часто, из-за проблемы как оно работает и какие ограничения предоставляет без регистрации.
Это все хорошо если у вас только pep и несколько юнит тестов. Но если у вас множество разные утилит, компиляторов и флагов…
Поэтому, мне кажется, лучше использовать ci. Для github это travis и appveyor.
Для кросс компиляторного использования #pragma, есть такое ключевое слово _Pragma.
Это аналог #pragma, но его можно использовать в макросах.
Т.е. можно объявить свою прагму, которая будет на пример работать только для clang, а gcc её будет игнорировать.
Примерно так:
#ifdef __clang__
#define PRAGMACLANG(str) _Pragma(#str)
#else
#define PRAGMACLANG(str)
#endif
И теперь в коде для заглушения какого-то предупреждения clang, можно написать:
PRAGMACLANG(clang diagnostic push)
PRAGMACLANG(clang diagnostic ignored "-Wsomething"
… здесь какой-то код…
PRAGMACLANG(clang diagnostic pop)
Также можно учитывать версию компиляторов, включенный стандарт C/C++ кода и т.д.
Такое если и случится, то очень редко.
Скорее при каких-то странных обстоятельствах вроде работающий винчестер выпадет из рейда. Это может как раз говорить о том, что с этим винчестером что-то не так, хотя он еще не умер.
Также для проверки такого состояния, иногда запускается синхронизация дисков в raid. Исправить подобную ошибку вряд ли сумеет, но найдет точно.
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
Но в таких играх проблемы ботов. Т.к. кто угодно может написать свой «клиент», и еще больше может запустить его.
В таких играх бывают также эксплойты, но это уже другое.
Но могут быть проблемы с LTO, если использовать одно имя функции с разными реализациями и атрибутами target.
Без lto, должно быть все хорошо. Либо можно обойти проблему использую функции с уникальными именами и собственную реализацию выбора функции на основе поддержки разных видов simd (я пока такое не делал)
Пример в wiki: https://gcc.gnu.org/wiki/FunctionMultiVersioning
Из недостатков, clang такое не поддерживает и надо обкладывать все через #ifdef/#define
Тесты в этом репозитории только для простых случаев. А ваш анализатор не только для простых.
Gcc также может многое, что могли бы находить анализаторы, на пример ошибки форматной строки, такие как переполнение буфера назначения. Или забытые скобочки, на основе анализа форматирования кода…
Я не противопоставляю gcc и pvs studio. Просто разработчики редко даже включают и проверяют предупреждения компилятора, не то что использует статические анализаторы. Если бы все исправляли все предупреждения компилятора, то и вы бы находили меньше проблем :)
А про nulll pointer, возможно вам стоит добавить еще один уровень предупреждений, которые по вашему мнению не интересны пользователям, но находят проблемы.
вот пример: https://godbolt.org/g/6NMDe6
Если есть перегруженный оператор сравнения, уже не найдет.
Часть расширений он просто игнорирует, на пример некоторые атрибуты.
Если писать скрипты для каждого инита, это будет слишком много. Видимо поэтому маинтейнеры выбирают те скрипты, которые везде будут работать.
И как может простой скрипт на баше упасть, и чтобы не упал init и другие процессы?
Хоть она и не от Линуса, но специально для линукс ядра.
Это называется SystemD. Сейчас это почти дистрибутив, за исключением загрузчика и графической части и да пока еще без сишной библиотеки.
В одном из проектов, где я участвую, для статического анализа используются почти все версии gcc и clang (да да они тоже многое могут найти с нужными флагами), различные cppcheck и множество других утилит и сервисов и не только статического анализа кода как такового но и стиля. В сожалению для вас, все это распространяется бесплатно. И хоть статический анализ и используется, но нет платных инструментов.
Pvs-studio тоже используется, но не часто, из-за проблемы как оно работает и какие ограничения предоставляет без регистрации.
Поэтому, мне кажется, лучше использовать ci. Для github это travis и appveyor.
Это аналог #pragma, но его можно использовать в макросах.
Т.е. можно объявить свою прагму, которая будет на пример работать только для clang, а gcc её будет игнорировать.
Примерно так:
#ifdef __clang__
#define PRAGMACLANG(str) _Pragma(#str)
#else
#define PRAGMACLANG(str)
#endif
И теперь в коде для заглушения какого-то предупреждения clang, можно написать:
PRAGMACLANG(clang diagnostic push)
PRAGMACLANG(clang diagnostic ignored "-Wsomething"
… здесь какой-то код…
PRAGMACLANG(clang diagnostic pop)
Также можно учитывать версию компиляторов, включенный стандарт C/C++ кода и т.д.
Скорее при каких-то странных обстоятельствах вроде работающий винчестер выпадет из рейда. Это может как раз говорить о том, что с этим винчестером что-то не так, хотя он еще не умер.
Также для проверки такого состояния, иногда запускается синхронизация дисков в raid. Исправить подобную ошибку вряд ли сумеет, но найдет точно.
Что-то около полугода назад: https://bugzilla.kernel.org/show_bug.cgi?id=108241