Мы используем куки, чтобы пользоваться сайтом
было удобно.
Это заметка о любви. О любви статического анализатора кода PVS-Studio к замечательной открытой операционной системе Linux. Эта любовь молода, трогательная и ранима. Этой любви нужно помочь укрепиться. Вы поможете, если заранее запишитесь в добровольцы для тестирования beta-версии PVS-Studio for Linux.
Я и мои коллеги очень долго отказывались обсуждать тему разработки PVS-Studio для операционной системы Linux и UNIX мира в целом. Дело не в каких-то личных пристрастиях или технических сложностях. Всё проще - это холодный, прагматический подход к развитию продукта.
Мы - маленькая компания, которая существует исключительно за счёт продажи программного продукта PVS-Studio. Мы не получаем гранты или какую-то иную поддержку от государства или больших компаний - всё это накладывает большую ответственность за выбор направления развития.
Сейчас мы накопили новых сил, собрались с духом и начинаем новую для нас тему освоения Linux. Да, да, это свершилось. Мы решились начать работы в этом направлении. Надеюсь, с этим у нас получится лучше, чем с CppCat.
Вначале кратко напомню, что сейчас представляет собой PVS-Studio, и что он умеет на данный момент. Если Вы уже читали наши статьи, то можете пропустить этот раздел.
PVS-Studio - это инструмент для выявления ошибок в исходном коде программ, написанных на языках С, C++ и C#. Анализатор до настоящего момента был ориентирован на разработчиков, использующих среду Visual Studio. Поддерживаемые языки и диалекты:
Основные особенности PVS-Studio:
Подробнее познакомиться с анализатором, а также скачать его можно на странице продукта PVS-Studio. Напоследок приведу сводную таблицу основных диагностических возможностей PVS-Studio. В таблицу включены не все диагностики, так как некоторые из них сложно классифицировать. Это не помешает составить общее впечатление, а подробно с имеющимися диагностиками можно познакомиться здесь.
Таблица 1 - Возможности PVS-Studio. Нажмите на рисунок для его увеличения.
Теперь собственно поговорим о том, ради чего многие начали читать эту статью: о поддержке Linux.
Эта задача не так проста, как может казаться на первый взгляд. Скомпилировать исполняемый модуль под Linux и что-то с его помощью проверить - задача нехитрая. Мы давно с ней справились. Ещё год назад мы писали статью об эксперименте про проверку Vim. Однако, это только маленькая часть всего объёма работ. Программисты забывают, что собрать исполняемый модуль и создать программный продукт — это далеко не одно и тоже.
Мы планируем поддержать GCC и Clang. Мы начали с GCC, а к Clang мы вернемся позднее. Расскажу о задачах, которые сейчас стоят перед нами.
Мне иногда кажется, что разработчикам компиляторов скучно, и они придумывают различные способы сделать себе жизнь сложнее, а заодно и разработчикам, реализующих подсветку кода, статический анализ и так далее. Другим способом я не могу объяснить зачем, например, понадобилось вводить Conditionals with Omitted Operands. Конечно, круто, что можно сократить тернарный оператор до: z = x ? : y;. На мой взгляд, без этого совершенно спокойно можно обойтись и жить счастливой жизнью.
Многих удивляет, почему надо заморачиваться с различными документированными и недокументированными расширениями компилятора. Кажется, достаточно анализировать С++, соответствующий стандарту и не обращать внимание на расширения, так как они используются крайне редко. К сожалению, это не так, и расширениям приходится уделять много времени.
Не важно, часто или нет встречаются в программе нестандартные сущности. В любой серьезной программе встретятся заголовочные файлы, содержащие какое-то из расширений. В результате это запутывает парсер в анализаторе, и он не может полноценно обработать множество *.cpp файлов, в которые включён этот злосчастный *.h файл. Конечно, в анализаторе PVS-Studio встроены механизмы, которые пытаются компенсировать ошибку разбора кода и продолжить анализ. К сожалению, этот механизм не всегда помогает. В результате могут возникать странные ложные срабатывания или наоборот, из анализа будет исключен фрагмент кода (до конца функции или класса, а то и всего файла).
Более того, всякие "хитрые" штучки любят использовать в системных заголовочных файлах. Так что на практике нарваться на какое-то расширение очень даже легко.
Если кому-то интересно, о чем всё-таки идёт речь, могу предложить взглянуть, например, на:
И это только документированные расширения. По опыту работы с Visual С++, мы ещё ожидаем наличие подлянок в форме недокументированных расширений.
Поскольку мы используем собственный парсер (развитие ныне забытой и заброшенной библиотеки OpenC++), то мы должны поддержать различные расширения.
Впрочем, используй мы какой-то другой парсер, это не сильно бы нам помогло. Например, если мы перепишем анализатор, взяв за основу Clang, нам все равно придётся самостоятельно сражаться с расширениями GCC, Visual C++.
Разрабатывая PVS-Studio, мы используем семь методик тестирования:
С точки зрения поддержки Linux, нам нужно в первую очередь расширить пункт N5 и N6. Пункт N5 пересекается с предыдущем разделом "Более полная поддержка GCC и Clang". Сделать тесты для проверки системных заголовочных файлов несложно, но трудоемко расширять парсер. Впрочем, про это мы уже говорили, и намного интересней пункт N6.
На самом деле, это самая большая и сложная из используемых у нас система тестирования. Вот, как выглядит эта программа в процессе работы:
Описывать этот инструмент в статье смысла нет, так как он предназначен исключительно для внутреннего использования. Скажу только, что он позволяет очень удобно отслеживать разработчикам результаты их правок в ядре анализатора и добавления новых диагностик.
Так вот, теперь нам предстоит создать аналог такой системы для Linux. Поскольку это очень важная часть процесса разработки анализатора, мы должны подойти к этой задаче со всей серьезностью. Так же нам нужно будет провести большую работу по подбору открытых проектов, на которых и будет осуществляться проверка работоспособности анализатора. С одной стороны, эти проекты не должны быть слишком большие, чтобы не сделать время проверки слишком долгим. С другой, они должны быть "насыщенными": в разных проектах должны использоваться различные подходы к программированию. То есть, желательно, чтобы где-то активно применялись операторы goto, где-то активно использовались шаблоны, где-то активно работали с Unicode и так далее. Это делает тестирование анализатора более всесторонним. Собрать такую коллекцию исходников весьма непростая задача, требующая время на изучение большого количества открытых проектов.
В состав PVS-Studio для Windows идёт GUI утилита Standalone.exe. С её помощью можно удобно работать с отчётами (*.plog-файлами), если не установлена среда разработки Visual Studio:
Но это не главное. Важнее то, что с помощью этой утилиты можно проверить проект, собираемый любой экзотичной или самописной сборочной системой. Впрочем, это не предназначается именно для экзотических ситуаций. Даже если у вас классический makefile, проще выполнить анализ с помощью Standalone, нежели разбираться с документацией PVS-Studio, чтобы прописать в maklefile вызов анализатора.
Standalone позволяет отслеживать запуски компиляторов Visual C++, GCC (MinGW), Clang и собирать всю необходимую для проверки информацию. Выглядит это следующим образом: вы говорите программе "начать слежку", после чего выполняете обыкновенную сборку проекта. Далее вы говорите программе "готово". Начинается анализ всех тех файлов, компиляция которых только что выполнялась.
Кстати, всё это не обязательно делать вручную. Вы можете использовать для проверки проекта на сервере консольную утилиту CLMonitor.exe. Она также собирает информацию о запущенных компиляторов и выполняет проверку проекта.
Реализуя Linux версию, мы сразу решили, что обязательно надо поддержать отслеживание запусков компилятора. Это поможет программистам быстрее и проще знакомиться с анализатором PVS-Studio. Дело в том, что, используя эту утилиту, проект сможет проверить любой член команды, не отвлекая людей, занимающихся поддержкой makefile-ов и вообще системы сборки. В больших проектах далеко не каждый знает, как собственно собирается их приложение. Тем более, не каждый найдет время и желание разбираться, как и куда прописать вызов PVS-Studio. Всё это ещё может быть усложнено наличием автогенерируемого makefile. Понятно, что во всём можно разобраться, но это является существенным барьером на пути первой проверки проекта и удовлетворения исследовательского любопытства.
Вот вы и познакомились с ещё одной подзадачей создания Linux-версии. Мы работаем над разработкой системы мониторинга запусков компиляторов и сборкой всей необходимой информации для проверки.
При написании документации мы всегда сталкиваемся с противоположными желаниями. С одной стороны, мы всегда старались, чтобы продукт оставался простым и понятным, и для работы с ним не нужно было знакомиться с большим руководством. С другой стороны, статический анализ — это достаточно сложный инструмент, и в руководстве должны быть отражены все тонкости работы с ним. Особенно это касается описания диагностических сообщений: их много, и надо чтобы каждое из них было подробно описано и сопровождалось примерами кода.
В результате нам предстоит большая работа по корректировке и пополнению документации разделами, посвященных работе в Linux. Плюс, нам надо придумать, как реализовать возможность пользователям быстро получать информацию по той или иной диагностике. В Visual Studio с этим нет проблем - достаточно нажать в списке предупреждений на код ошибки и откроется соответствующая страница.
Как и что предложить в среде Linux — надо думать. Конечно, всегда есть PDF файл (на 350 страниц) или online документация на сайте, но это нельзя назвать удобным способом доступа к описанию диагностик.
Сайт, естественно, тоже потребует доработки. Это не программистская задача, но заниматься ей надо, поэтому я решил упомянуть сайт в обучающих целях. Многие программисты думают только о коде и забывают, что в выпуске продукта участвует много других коллег, решающих большое количество скрытых от них задач.
Естественно, не надо забывать о тестировании. Хотя многоуровневые тесты выявят большинство проблем, наверняка проявят себя какие-то совершенно неожиданные ошибки или недоработки. Сейчас даже невозможно предположить, что это будет, но мы не питаем иллюзий об идеальности мира. Под Windows мы столкнулись с разнообразнейшими ситуациями, когда вроде и не мы виноваты, но что-то работает неправильно. О некоторых таких неприятных неожиданностях я рассказывал в интервью около 2 лет назад (ищите в статье фразу "К сожалению, вся красота и надежность внутреннего кода иногда разваливается из-за воздействий враждебной окружающей среды"). Уверен, в Linux нас поджидают аналогичные сюрпризы.
Результаты нашей работы надо обернуть в дистрибутив, который можно легко скачать и использовать. Сказать это намного проще, чем сделать. Думаю, понадобится не одна итерация, чтобы сделать это удобным и учесть различные тонкости.
И последнее: мы должны организовать поддержку нового направления. Наши пользователи ценят нас за качественную и оперативную поддержку. С выходом Linux версии увеличится количество запросов, особенно вначале, когда далеко не всё будет работать, и мы должны быть к этому готовы.
Выше я описал далеко не всё, на что нам нужно будет потратить время, чтобы адаптировать PVS-Studio к Linux. Есть масса более мелких задач, о которых сразу не вспомнишь, да и писать про них неинтересно. Например, мне надо написать эту и множество других статей, которые расскажут людям о том, что появился PVS-Studio для Linux.
Есть и большие задачи, которыми мы займемся позже. Например, как я уже говорил, вначале мы сосредоточились на GCC, и только потом планируем позаниматься с Clang. Я пока даже не знаю, будет ли в первой релизной версии PVS-Studio для Linux поддержка Clang или нет.
Вот еще некоторые из больших задач, которые ожидают нас:
Мы с нетерпением ожидаем, когда можно будет что-то представить миру. Надеюсь, я вас заинтересовал, и многим Linux-разработчикам хочется попробовать проверить свои проекты. Если у вас есть желание и время, приглашаю вас заранее вступить в группу beta-тестеров.
Итак, если вы хотите помочь нам проверить работу PVS-Studio для Linux прошу написать нам. Чтобы письма можно было проще обрабатывать, просим указать в теме письма строчку "PVS-Studio for Linux, Beta". Письма отправляйте по адресу support@viva64.com. Просим писать письма с корпоративных ящиков и кратко представиться. Мы будем благодарны всем, кто откликнется, но в первую очередь будем уделять внимание тем людям, которые потенциально со временем могут стать нашими клиентами.
Также прошу в письме дать ответы на следующие вопросы:
Когда появится версия, которую можно будет попробовать, мы напишем всем откликнувшимся письма.
Заранее всем спасибо. Мы будем временами упоминать в статьях, как продвигается развитие PVS-Studio для Linux. Желаю всем пореже запускать отладчик!
0
0
0
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
0