VivaCore – это открытая библиотека для работы с C и C++ кодом. Библиотека предназначена для реализации на ее основе систем рефакторинга кода, систем статического и динамического анализа, систем трансформации или оптимизации кода расширений языка, подсистем подсветки синтаксиса, систем построения документации по коду и других аналогичных инструментов.
Идея разработки библиотеки возникла в процессе создания нашей командой статического анализатора кода Viva64 [1]. Инструмент Viva64 предназначен для диагностирования ошибок в программах на C/C++, связанных с особенностями переноса кода под 64-битные Windows-системы.
В процессе разработки Viva64 наша команда столкнулась с отсутствием открытых библиотек, удобных для реализации подобных проектов. В качестве основы была выбрана библиотека OpenC++ [2], и в целом мы остались довольны своим выбором. Но в ходе разработки статического анализатора наша команда внесла довольно большое количество исправлений и усовершенствований в библиотеку OpenC++. И теперь, когда разработка первых версий продукта Viva64 закончена, мы хотим предложить сторонним разработчикам наш переработанный вариант библиотеки OpenC++, которую мы назвали VivaCore. Мы считаем, что внесенные нами изменения могут существенно облегчить жизнь разработчикам, собирающимся приступить к разработке продуктов в области анализа или обработки C/C++ кода.
Лицензия на библиотеку VivaCore позволяет свободно использовать, копировать, распространять и модифицировать ее в бинарном виде или в виде исходного кода, как для коммерческого, так и для некоммерческого использования без каких-либо отчислений авторам библиотеки. Необходимо лишь указать авторов исходных библиотек (OpenC++ и VivaCore).
Основное отличие библиотеки VivaCore от OpenC++ заключается в том, что она является живым проектом и продолжает активно наращивать функциональность. Библиотека OpenC++, к сожалению, давно не развивается. Самое последнее изменение библиотеки датируется 2004 годом. А последнее изменение, связанное с поддержкой новых ключевых слов, датируется 2003 годом. Этим исправлением является неудачная попытка добавить тип данных wchar_t, что повлекло за собой внесение около пяти ошибок различного рода.
Очевиден вопрос, почему мы предлагаем свою библиотеку, а не внесли свои изменения в OpenC++? У нас нет для этого достаточного количества свободных ресурсов. Было осуществлено огромное количество модификаций, и внести все имеющиеся изменения в OpenC++ представляется сложной задачей. Многие из изменений носят специфический характер и могут не вписываться в общую идеологию библиотеки OpenC++, а значит, потребуют дополнительной адаптации. Все это делает задачу обновления библиотеки OpenC++ весьма ресурсоемкой задачей, и с нашей точки зрения – не очень целесообразной.
Перечислим новые по сравнению с OpenC++ ключевые функциональные возможности, реализованные в библиотеке VivaCore:
Поддержан классический язык C. Используется другой набор лексем, что дает возможность именовать переменные именем "class" или объявить функцию в следующем классическом С-стиле:
PureC_Foo(ptr)
char *ptr;
{
...
}
Проделана большая работа по поддержке специфики синтаксиса языка C++, используемого при разработке в среде VisualStudio 2005/2008. Например, библиотека обрабатывает ключевые слова __noop, __if_exists, __ptr32, __pragma, __interface и так далее.
Поддержаны некоторые новые ключевые слова и иные конструкции, имеющиеся в новых стандартах языка. В частности, добавлено ключевое слово register и поддержан вызов шаблонных функций с использованием слова template: object.template foo<int>();.
Библиотека адаптирована и оптимизирована для работы на 64-битных системах с помощью анализатора кода Viva64.
Исправлено большое количество ошибок и недочетов. Примерами может служить поддержка строковых литералов, разделенных пробелом (const wchar_t *str = L"begin" L"end") или разделенных на две строки косой чертой: const char *name = "Viva\ Core"; Другой пример - это корректная обработка выражений вида "bool r = a < 1 || b > (int) 2;", которые OpenC++ путает с шаблонами. И так далее.
Создан механизм начальной предобработки исходного текста, позволяющий реализовать некоторые специфические модификации кода.
В ближайшем будущем в библиотеке VivaCore планируется реализовать:
Собственный препроцессор (на основе The Wave C++ preprocessor library) вместо стороннего (например, препроцессора Visual Studio). Это позволит избежать ряда ошибок позиционирования по номерам строк в коде, при выводе ошибок компиляции, а также обеспечить больший контроль над процессом разбора и анализа кода.
Поддержать кодирование сложных типов, занимающих в кодированном виде более 127 символов.
Простое приложение, демонстрирующие основные принципы использования библиотеки VivaCore.
Необходимо отметить, что, несмотря на все указанные отличия библиотек OpenC++ и VivaCore, в них много общего, и поэтому документация по OpenC++ не утрачивает своей актуальности. Наша команда постарается уделить внимание документированию библиотеки VivaCore. Но поскольку эта документация будет в первую очередь затрагивать отличия и новые возможности, реализованные в библиотеке VivaCore, то знакомство с документацией по библиотеке OpenC++ будет полезно в любом случае.
Области применения библиотеки VivaCore
Библиотека VivaCore может быть интересна компаниям и организациям, которые создают или планируют создавать инструменты для работы с кодом. Перечислить все допустимые области и методы применения, естественно, невозможно, но мы все-таки назовем ряд направлений, чтобы показать VivaCore под разными углами зрения. В скобках указаны продукты, относящиеся к данному классу решений. Не стоит считать, что они реализованы на основе VivaCore – это всего лишь примеры решений. Итак, с помощью VivaCore возможно разработать:
системы построения документации по коду (Synopsis, Doxygen);
высокоточное определение изменений в исходном коде или анализа эволюции изменений;
поиск дублирующегося кода на уровне грамматических конструкций языка;
подсчет метрик (C and C++ Code Counter - CCCC);
поддержку стандартов кодирования (Gimpel Software PC-Lint);
инструменты, облегчающие миграцию кода на другие программные и аппаратные платформы (Viva64);
автоматическую генерацию кода;
визуализаторы кода, системы построения диаграмм зависимостей (Source-Navigator);
форматирование кода (Ochre SourceStyler).
Более подробно о применении технологии разбора кода можно узнать из фундаментальной книги по компиляторам [3]. Также рекомендуем ознакомиться с принципами анализа программ [4].
Не следует путать VivaCore с профессиональными многофункциональными парсерами C/C++-кода. Если пользователю нужен front-end парсер кода, полностью поддерживающий современный стандарт языка C++ и позволяющий создать свой компилятор под специфическую платформу, то ему стоит обратить свое внимание на GCC или дорогие коммерческие решения. Например, такие решения предоставляет Semantic Designs [5].
Но если компания разрабатывает инструмент, требующий классического анализа C/C++-кода, то рациональным решением будет являться использование удобной и открытой библиотеки кода, которой и является VivaCore.
Основные термины
Прежде чем перейти к более подробному рассмотрению библиотеки VivaCore, введем некоторые термины, которые будут использоваться в процессе описания.
Препроцессирование – механизм, просматривающий входной ".c/.cpp" файл, исполняющий в нём директивы препроцессора, включающий в него содержимое других файлов, указанных в директивах #include и прочее. В результате получается файл, который не содержит директив препроцессора, все используемые макросы раскрыты, вместо директив #include подставлено содержимое соответствующих файлов. Файл с результатом препроцессирования обычно имеет суффикс ".i". Результат препроцессирования называется единицей трансляции.
Синтаксический анализ (парсинг) – это процесс анализа входной последовательности символов, с целью разбора грамматической структуры. Обычно синтаксический анализ делится на два уровня: лексический анализ и грамматический анализ.
Лексический анализ – процесс обработки входной последовательности символов с целью получения на выходе последовательности символов, называемых лексемами (или «токенами»). Каждую лексему условно можно представить в виде структуры, содержащей тип лексемы и, если нужно, соответствующее значение.
Грамматический анализ (грамматический разбор) – это процесс сопоставления линейной последовательности лексем (слов, лексем) языка с его формальной грамматикой. Результатом обычно является дерево разбора или абстрактное синтаксическое дерево.
Абстрактное синтаксическое дерево (Abstract Syntax Tree – AST) – конечное, помеченное, ориентированное дерево, в котором внутренние вершины сопоставлены с операторами языка программирования, а листья с соответствующими операндами. Таким образом, листья являются пустыми операторами и представляют только переменные и константы. Абстрактное синтаксическое дерево отличается от дерева разбора (derivation tree – DT, parse tree – PT) тем, что в нём отсутствуют узлы для тех синтаксических правил, которые не влияют на семантику программы. Классическим примером такого отсутствия являются группирующие скобки, так как в AST группировка операндов явно задаётся структурой дерева.
Метапрограммирование – создание программ, которые создают другие программы как результат своей работы, либо изменяющие или дополняющие себя во время выполнения. Под метапрограммированием в рамках библиотеки VivaCore следует понимать возможность расширения синтаксиса и функциональности языка C/C++ с целью создания собственного языка программирования. Созданные метапрограммы на этом языке программирования затем могут быть транслированы с использованием VivaCore в код на языке C/C++ и скомпилированы внешним компилятором.
Обход синтаксического дерева – обход всех вершин и листьев синтаксического дерева с целью сбора информации различного рода, анализа или модификации.
Общая структура библиотеки VivaCore
Общая функциональная структура библиотеки VivaCore показана на рисунке 1. На данный момент библиотека рассчитана на плотную интеграцию с пользовательским приложением и представлена в виде набора исходных текстов.
Рисунок 1 - Общая функциональная структура библиотеки VivaCore.
Мы предлагаем рассмотреть функциональные блоки библиотеки в том порядке, в котором они обрабатывают поступивший на вход исходный текст программы, как показано на рисунке 2. Мы рассмотрим, какие действия выполняет функциональный блок, какую информацию он позволяет получить и как его можно модифицировать для специфических целей.
Рисунок 2 - Последовательность обработки кода.
1) Подсистема ввода данных (Input subsystem)
Библиотека VivaCore может корректно использовать только исходный С/С++-код, обработанный препроцессором. В дальнейшем рассматривается возможность использовать препроцессор из The Wave C++ preprocessor library, но в первой версии библиотеки это реализовано не будет. Для получения файла, обработанного препроцессором, можно воспользоваться компилятором (например, Microsoft Visual C++) и получить обработанный файл, который обычно имеет расширение "i".
В определенных случаях можно подать на вход необработанные С/С++-файлы, но в этом случае работать с VivaCore следует не дальше уровня разбиения файла на лексемы. Этого вполне может хватить для подсчета метрик или иных целей. Но пытаться строить и анализировать дерево разбора (PT) не стоит, поскольку результат, скорее всего, будет малопригоден для обработки.
Имея обработанный препроцессором код, пользователь может передать его подсистеме ввода данных в виде файла или буфера в памяти. Назначение подсистемы ввода заключается в том, чтобы расположить переданные данные во внутренних структурах библиотеки VivaCore. Также подсистема ввода принимает конфигурационные данные, которые сообщают, что считать системными, а что пользовательскими библиотеками.
См. в коде: VivaConfiguration, ReadFile.
2) Подсистема предварительной обработки кода (Preprocessor subsystem)
Хочется подчеркнуть, что данная подсистема не выполняет обработку кода препроцессором в ее классическом понимании. Как было сказано ранее, обработанный препроцессором код уже должен быть подан на вход библиотеки VivaCore. Рассматриваемая подсистема служит для следующих задач:
Разбиение текста программы на строки и разбиение их на две логических группы. К первой группе относится системный код (код библиотек компилятора и так далее). Ко второй пользовательский код, который представляет интерес для анализа. В результате, разрабатывая статический анализатор, пользователь получает возможность решать, будет ли он анализировать код системных библиотек или нет.
Специализированная модификация текста программы в памяти. Примером может служить удаление из кода конструкций конкретной среды разработки, не имеющих отношения к языкам C или C++. Например, анализатор Viva64 при своей работе убирает такие ключевые конструкции, как SA_Success или SA_FormatString, имеющиеся в заголовочных файлах Visual Studio.
См. в коде: VivaPreprocessor, CreateStringInfo, IsInterestingLine, GetLineNumberByPtr, PreprocessingItem, SkipUninterestingCode.
3) Лексический анализатор (Lexer)
Вот мы и добрались до тех уровней обработки данных, которые представляют практический интерес для разработчиков. Разобрав код на лексемы, пользователь имеет возможность посчитать многие метрики, реализовать специфический алгоритм подсветки синтаксиса в различных приложениях.
Лексический анализатор VivaCore разбирает текст программы на набор объектов типа Token (см. файл Token.h), которые содержат информацию о типе лексемы, ее местонахождении в тексте программы, а также длину лексемы. Типы лексем перечислены в файле tokennames.h. Примеры типов лексем:
CLASS – ключевое слово языка "class"
WCHAR – ключевое слово языка "wchar_t"
В случае необходимости пользователь может расширить набор лексем. Это может быть востребовано в случае поддержки специфического синтаксиса конкретной реализации языка или при разработке своего языкового расширения.
При добавлении лексем необходимо объявить их в файле tokennames.h и добавить в таблицы "table" или "tableC" в файле Lex.cc. Первая таблица предназначена для обработки C++ файлов, а вторая – для C файлов. Это естественно, так как набор лексем в языке C и C++ различен. Например, в языке C отсутствует лексема CLASS, так как в C слово "class" не является ключевым и может обозначать имя переменной.
При добавлении новых лексем следует проявить аккуратность и не забыть скорректировать функции isTypeSpecifier, optIntegralTypeOrClassSpec и так далее. Чтобы не пропустить важное место, лучше всего взять близкое по значению ключевое слово и найти все места, где в VivaCore используется соответствующая лексема.
Получить набор лексем можно как в виде простого массива, так и выгрузив их в файл. Лексемы хранятся в массиве tokens_ в классе Lex. Возможно получить как массив целиком, так и перебрать лексемы по отдельности, используя функции GetToken, LookAhead, CanLookAhead.
Пользователь может получить лексемы в виде неструктурированного текста или используя функцию DumpEx в следующем отформатированном виде:
258
LC_ID
5
258
lc_id
5
91
[
1
262
6
1
93
]
1
59
;
1
303
struct
6
123
{
1
282
char
4
42
*
1
258
locale
6
Пользователь также может экспортировать лексемы в формате XML-файла.
См. в коде: Token, Lex, TokenContainer.
4) Грамматический анализатор (Parser)
Грамматический анализатор предназначен для построения дерева разбора (derivation tree, DT), которое в дальнейшем может быть подвергнуто анализу и трансформации. Обратите внимание, что грамматический анализатор библиотеки VivaCore строит не абстрактное синтаксическое дерево (АST), а именно дерево разбора. Это позволяет более просто осуществлять поддержку метапрограммных конструкций, добавляемых пользователем в язык C или C++. Если пользователю будет необходимо работать именно с абстрактным синтаксическим деревом, то мы надеемся, что будет несложно доработать анализатор так, чтобы он проходил полное дерево разбора и удалял узлы и листья, которые не используются в абстрактном синтаксисе.
Построение дерева в библиотеке VivaCore происходит в функциях класса Parser. Узлами и листьями дерева являются объекты, классы которых наследуются от базовых классов NonLeaf и Leaf. На рисунке 3 показана часть иерархии классов, используемых для представления дерева.
Рисунок 3. Часть иерархии классов, используемых для построения дерева разбора.
Как видно из рисунка, класс Ptree является базовым классом для всех остальных и служит для организации единого интерфейса для работы с другими классами. В классе Ptree имеется набор чистых виртуальных функций, реализуемых в потомках. Например, функция "virtual bool IsLeaf() const = 0;" реализуется в классах NonLeaf и Leaf. Практически классы реализуют только эту функцию и нужны для того, чтобы сделать иерархию классов более логичной и красивой.
Поскольку работа с деревом занимает существенный объем библиотеки, то в Ptree имеется большой набор функций для работы с узлами дерева. Для удобства эти функции являются аналогами функций работы со списками в языке Lisp. Вот некоторые из них: Car, Cdr, Cadr, Cddr, LastNth, Length, Eq.
Чтобы получить общее представление о работе грамматического анализатора, в качестве примера приведем дерево разбора, которое будет построено из следующего кода:
int MyFoo(constfloat value)
{
if (value < 1.0)
returnsizeof(unsignedlong *);
return value * 4.0f < 10.0f ? 0 : 1;
}
К сожалению, целиком дерево разбора изобразить не удастся, поэтому изобразим его по частям на рисунках 4.1-4.4.
Рисунок 4.1. Цветовые обозначения узлов семантического дерева.
Рисунок 4.2. Представление заголовка функции.
Рисунок 4.3. Представление тела функции.
Рисунок 4.4. Представление тела функции.
Следует упомянуть еще один важный компонент работы анализатора. Это получение информации о типах различных объектов (функциях, переменных и так далее), которое осуществляется в классе Encoding. Информация о типе представляется в виде специально закодированной строки, с форматом которой можно познакомиться в файле Encoding.cc. В библиотеке существует также специальный класс TypeInfo, позволяющий извлекать информацию о типах, а также модифицировать ее. Например, используя такие функции как IsFunction, IsPointerType, IsBuiltInType, можно легко идентифицировать тип обрабатываемого элемента.
Описание подходов к добавлению новых типов узлов или листьев является нетривиальной задачей и не может быть изложено в этой обзорной статье. Рациональным решением будет выбор одного из классов, например PtreeExprStatement и просмотр всех мест в коде, где происходит создание объектов данного класса, работа с ними и так далее.
Полученное по завершению дерево разбора может быть сохранено в формате ".с/.cpp"-файла, что, впрочем, на данном этапе имеет мало смысла. Сохранив дерево сейчас в виде кода программы, мы получим ровно то, что получили на входе. Впрочем, это может быть вполне полезно для тестирования изменений, внесенных в лексер и парсер. Смысл в сохранении появляется после изменения дерева разбора, которое может произойти на следующих этапах.
Больший интерес представляет возможность сохранить дерево для дальнейшей обработки в произвольном формате, реализованном пользователем. Примером может служить следующее текстовое представление кода, приводившегося выше:
Данный формат показан просто для примера. На практике, скорее всего, потребуется сохранять больше информации и в более удобном для обработки формате – например, в формате XML.
См. в коде: Parser, Ptree, Leaf, NonLeaf, Encoding, TypeInfo, Typeof, PtreeUtil.
5) Обход дерева разбора
Для разработчиков статических анализаторов кода (подробное введение в задачу – книга [6]) или систем построения документации по коду наибольший интерес должен представлять этап обхода дерева разбора, выполняемый с использованием классов Walker, ClassWalker, ClassBodyWalker. Обход дерева разбора можно выполнять несколько раз, что позволяет создавать системы, модифицирующие код за несколько проходов, или проводить анализ, учитывающий знания, накопленные при предыдущих обходах дерева.
Класс Walker служит для обхода базовых конструкций языка C/C++.
Класс ClassWalker наследуется от класса Walker и добавляет функциональность, связанную со спецификой классов, присутствующих в языке C++.
Если необходимо разобрать тело класса, временно создаются и используются объекты класса ClassBodyWalker.
Если не вносить никаких изменений в библиотеку VivaCore, то будет происходить простой проход по всем элементам дерева. При этом само дерево не будет изменяться.
Если пользователь реализует функциональность, модифицирующую вершины дерева, библиотека может перестроить дерево. Для примера рассмотрим код, транслирующий унарные операции:
Обратите внимание, что если при трансляции выражения, стоящего справа от унарной операции, полученное дерево будет изменено, то будет изменен (пересоздан) и узел унарной операции. Это, в свою очередь, может повлечь перестройку и вышестоящих узлов.
Для наглядности рассмотрим этот пример более подробно.
Начинается обработка узла, представляющего собой унарную операцию над некоторым выражением и имеющего тип PtreeUnaryExpr. Первым элементом в списке, который извлекается с помощью операции exp->Car(), является непосредственно унарная операция. Вторым элементом, извлеченным с помощью PtreeUtil::Second(exp), является выражение, к которому применяется унарная операция.
Происходит трансляция выражения и результат помещается в переменную right2. Если этот адрес отличается от имеющегося, то это означает, что выражение было изменено. В этом случае происходит создание нового объекта типа PtreeUnaryExpr, которое и будет возвращено из функции TranslateUnary. В противном случае ничего не изменяется, и возвращается тот же объект, что и поступил на вход.
Если пользователю потребуется производить сбор информации при обходе дерева, или производить его модификацию, то самым естественным образом будет наследоваться от классов ClassWalker и ClassBodyWalker.
Покажем пример, взятый из статического анализатора Viva64, в котором происходит специализированный анализ при проходе через оператор "throw":
Ptree* VivaWalker::TranslateThrow(Ptree *p) {
Ptree *result = ClassWalker::TranslateThrow(p);
Ptree* oprnd = PtreeUtil::Second(result);
if (oprnd != NULL) { //if oprnd==NULL then this is "throw;".if (!CreateWiseType(oprnd)) {
return result;
}
if (IsErrorActive(115) &&
!ApplyRuleN10(oprnd->m_wiseType.m_simpleType))
{
AddError(VivaErrors::V115(), p, 115);
}
}
return result;
}
Вначале с помощью ClassWalker::TranslateThrow(p) выполняется стандартная трансляция узла. После этого выполняется необходимый анализ. Все просто и очень изящно.
Говоря об обходе дерева, следует также сказать об очень важном классе Environment, обеспечивающем получение информаций о типах различных объектов в различных областях видимости.
Пример использования класса Environment, представленного объектом env для получения типа объекта declTypeInfo:
TypeInfo declTypeInfo;
if (env->Lookup(decl, declTypeInfo))
{
...
}
См. в коде: AbstractTranslatingWalker, Walker, ClassWalker, ClassBodyWalker, Class, Environment, Bind, Class, TemplateClass.
6) Поддержка метапрограммирования
Метапрограммирование основано на подходе к генерации кода, когда код программы не пишется вручную, а создается автоматически программой-генератором на основе другой, более простой программы. Такой подход приобретает смысл, если при программировании вырабатываются различные дополнительные правила (более высокоуровневые парадигмы, выполнение требований внешних библиотек, стереотипные методы реализации определенных функций). При этом часть кода теряет содержательный смысл и становится лишь механическим выполнением правил. Когда эта часть становится значительной, возникает мысль задавать вручную лишь содержательную часть, а остальное добавлять автоматически. Этим и занимается генератор.
Иногда такой генератор необходим для трансляции придуманного языка в операторы языка C или C++. В VivaCore имеется механизм для удобного создания расширений языка C/C++ на базе метаобъектов. Возможно менять или строить новые синтаксические деревья с целью сохранения их в код на языке C/C++.
Подробно познакомиться с парадигмой метапрограммирования и методами использования метаобъектов можно в документации библиотеки OpenC++.
См. в коде: Metaclass.
7) Сохранение результатов
Как уже говорилось, можно сохранять необходимую информацию на любом этапе процесса обработки исходного кода внутри библиотеки VivaCore. В том числе мы упоминали, что полученное и измененное дерево разбора можно сохранить в виде текста программы или любом ином формате. Не будем повторяться. Так же понятно, что подойти к задаче сбора необходимой информации, например при статическом анализе или подсчете метрик, можно разными способами, и поэтому нет смысла перечислять способы реализации.
Остановимся только на использовании формата XML, который уже неоднократно упоминался в статье. XML - это текстовый формат, предназначенный для хранения структурированных данных для обмена информацией между программами или разными подсистемами обработки информации. XML является упрощённым подмножеством языка SGML.
Мы используем XML для экспорта различной информации в надежде, что это облегчит сторонним разработчикам использование библиотеки VivaCore в своих программных разработках на других языках программирования. Например, это будет весьма удобно для C#-программ. И, что немаловажно, выбор XML в качестве формата хранения данных позволяет легче структурировать информацию и представлять ее в привычной для программиста форме.
Заключение
Мы понимаем, что после прочтения этой статьи может возникнуть больше новых вопросов о VivaCore, чем было получено ответов. Но наша команда Viva64.com всегда открыта к общению, и мы готовы обсудить возникшие вопросы и дать рекомендации по использованию VivaCore. Пишите нам!
Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools (2nd Edition). Addison Wesley, 2006, 1000 pages.
Flemming Nielson, Hanne R. Nielson, Chris Hankin. Principles of Program Analysis. Springer, 2004, 452 pages.
