Содержание к диссертации
Введение
Глава 1. Постановка задачи переноса приложений на 64-битные платформы
1.1 Проблема переноса приложений на 64-битные платформы 16
1.2 Способы тестирования приложений для подтверждения корректности переноса кода
1.2.1 Просмотр кода 22
1.2.2 Статический анализ кода 23
1.2.3 Динамический анализ кода 23
1.2.4 Метод белого ящика 24
1.2.5 Метод черного ящика 25
1.2.6 Ручное тестирование 26
1.3 Основные задачи исследования 26
Глава 2. Статический анализ кода как наиболее удобное решение для проверки корректности 64-битных программ 28
2.1 Применение статического анализа кода при разработке программ 28
2.1.1 Процесс анализа 30
2.1.2 Дерево кода 33
2.1.3 Методы статического анализа 34
2.2 Разработка статического анализатора: требования, архитектура, реализация 37
2.2.1 Требования к анализатору кода 37
2.2.2 Архитектура анализатора кода 38
2.2.3 Реализация анализатора кода 44
Глава 3. Обнаружение ошибок при переносе программ на 64-битные платформы 47
3.1 Примеры потенциально-опасных конструкций в коде программ на языке Си++ 47
3.1.1 Использование функций с переменным количеством аргументов...51
3.1.2 Магические константы 52
3.1.3 Хранение в double целочисленных значений 56
3.1.4 Операции сдвига 57
3.1.5 Упаковка указателей 59
З.І.бМептзіге-типьів объединениях 61
3.1.7 Изменение типа массива 63
3.1.8 Виртуальные функции с аргументами THnamemsize 64
3.1.9 Сериализация и обмен данными
3.1.10 Битовые поля 68
3.1.11 Адресная арифметика с указателями 71
3.1.12 Индексация массивов 73
3.1.13 Смешанное использование простых целочисленных типов и memsize-типов 76
3.1.14 Неявные приведения типов при использовании функций 80
3.1.15 Перегруженные функции 81
3.1.16 Выравнивание данных 82
3.1.17 Исключения 85
3.1.18 Использование устаревших функций и предопределенных констант 86
3.1.19 Явные приведения типов 86
3.2 Правила статического анализа кода для диагностики потенциально опасных конструкций 87
3.2.1 Приведение 32-битных целых типов к memsize-типам 89
3.2.2 Приведение memsize-типов к целым 32-битным типам 90 3.2.3 Memsize-типы в виртуальных функциях 90
3.2.4 Memsize-типы в перегруженных функциях 91
3.2.5 Приведение типов указателей на memsize-типы 92
3.2.6 Приведение memsize-типов к double 92
3.2.7 Memsize-типы в функции с переменным количеством аргументов .93
3.2.8 Опасные константы 93
3.2.9 Memsize-типы в объединениях 94
3.2.10 Исключения и memsize-типы 94
3.3 Методика создания новых правил диагностики ошибок 95
Глава 4. Программный комплекс для статического анализа 64-битных приложений Viva64 97
4.1 Обзор программы Viva64 97
4.2 Сравнение диагностических возможностей современных анализаторов при проверке 64-битного кода 101
4.3 Применение Viva64 для проверки CAD-системы Leios Studio 105
4.3.1 Библиотека компонентов Leios Components 106
4.3.2 Программный интерфейс для работы с облаками точек и триангулированными сетками 107
4.3.3 Библиотека подгонки деталей 109
4.3.4 Библиотека обработки граней и ребер 110
4.3.5 Необходимость миграции библиотеки компонентов на 64-битную платформу 111
4.3.6. Участие компании ООО «СиПроВер» в миграции библиотеки
компонентов 112
Заключение 114
Список использованных источников
- Динамический анализ кода
- Разработка статического анализатора: требования, архитектура, реализация
- Виртуальные функции с аргументами THnamemsize
- Сравнение диагностических возможностей современных анализаторов при проверке 64-битного кода
Введение к работе
Актуальность темы. Персональные компьютеры с 64-битными процессорами появились на массовом рынке, в начале 2006 года. Практически сразу же начался процесс модификации программ для работы на новой архитектуре. Но неожиданно для разработчиков выяснилось, что после запуска на новой платформе приложения могут вести себя некорректно. Стандартные средства диагностики не позволяют выявить новый класс ошибок в приложениях, но оставлять эти ошибки неисправленными нельзя.
Столкнувшись с необходимостью переноса существующих приложений на новую 64-битную систему, разработчики программного обеспечения оказываются в необычном для себя положении. Программы, работавшие стабильно много лет, начинают вести себя непредсказуемым образом. Программам стало доступно больше оперативной памяти. Однако при попытке обработки больших, чем ранее, объемов данных, приложение может зависнуть, аварийно завершиться или, что еще хуже, вместо файлов с результатами работы выдать пользователю файлы с мусором.
Казалось бы, раз более или менее известны проблемы, возникающие в коде при миграции приложений на 64-битные платформы, то надо просто писать программы без ошибок. Однако это возможно только для новых программных продуктов, которые сразу же разрабатываются для 64-битной архитектуры. Большинство же существующих программ приходится переносить на новую архитектуру. Очевидно, что поиск ошибок в миллионах строк кода уже существующих приложений, которые безошибочно функционировали на 32-битных системах, без средств автоматизации ие возможен.
Одним из возможных решений для поиска ошибок при переносе кода является использование программ специального класса - статических анализаторов кода.
Вопросами повышения качества программного обеспечения занимаются С. Макконнел, М. Фаулер, С. Майерс, в России - В.В. Липаев. Проблемами 64-битного кода - М. Штрек, А.Зейчик, М. Уолл, К.С. Гэтлин, А. МакНаутон. Разработкой статических анализаторов занимаются С. Гутз, А. Колава. Недостатком работ данных авторов является тот факт, что они не уделяли внимание автоматизированному обнаружению ошибок в 64-битных приложениях. Они обращали свое внимание либо на различные методики обучения программистов написанию качественного кода, либо на другие способы повышения качества. При этом автоматизированное обнаружение ошибок рассматривалось лишь для наиболее традиционных ошибок программистов - 64-битный код оставался в стороне.
Объектом исследования является процедура миграции (переноса) программного обеспечения с 32-разрядной на 64-разрядную платформу.
Предметом исследования являются правила диагностики потенциально опасных синтаксических конструкций в коде программ на языках Си и Си++.
Цель диссертации. Целью работы является повышение качества программных продуктов и сокращение количества программных ошибок во время процедуры миграции программного обеспечения на 64-битные платформы. Для достижения этой цели разработаны правила диагностики потенциально опасных синтаксических конструкций и реализован программный продукт в виде статического анализатора кода для проверки корректности процесса переноса программ на языках Си и Си++ на 64-битную платформу.
Основные задачи исследования.
Исследование потенциально опасных синтаксических конструкций и выражений в коде программ на языках программирования Си и Си++, которые могут привести к ошибкам в программах при переносе их кода с 32-битных на 64-битные платформы.
Разработка правил диагностики выявленных потенциально опасных синтаксических конструкций в виде, доступном для автоматизированного обнаружения ошибок в программах; разработка методики создания новых правил диагностики ошибок миграции.
Реализация на основе разработанных правил статического анализатора кода, выявляющего соответствующие ошибки в исходном коде программе
Сравнительный анализ разработанного статического анализатора кода с альтернативными инструментами.
Исследование применимости разработанного статического анализатора кода на примере диагностики ошибок в реальном программном продукте.
Методы исследования - методы теории множеств, теории формальных языков, теории графов, методы программирования на языках высокого уровня.
Научная новизна работы. Научная новизна работы заключается в следующем:
Проведено исследование и выполнена систематизация потенциально опасных синтаксических конструкций и выражений в коде программ на языках программирования Си и Си++, которые могут привести к ошибкам в программах при переносе их кода с 32-битных на 64-битные платформы.
Впервые предложены классы для систематизации ошибок: приведения memsize-типов, функции с параметрами memsize-типов, синтаксические конструкции с memsize-типами, использование «магических» чисел.
Разработаны формальные правила диагностики ошибок, возникающих при переносе кода на 64-битные архитектуры, отличающиеся от эвристических, не описанных строго методов диагностики существующих программных продуктов.
Разработана методика создания новых правил диагностики ошибок в программах при переносе их кода с 32-битных на 64-битные платформы.
Положення, выносимые на защиту. На защиту выносятся следующие положения:
Систематизация потенциально опасных синтаксических конструкций в коде программ на языках программирования Си и Си++, которые могут привести к ошибкам в программах при переносе их кода с 32-битных и на 64-битные платформы.
Классы ошибок, возникающих в приложениях при миграции на 64-битную платформу.
Формальные правила диагностики ошибок, возникающих при переносе кода на 64-битныс архитектуры.
Методика создания новых правил диагностики ошибок в программах при переносе их кода с 32-битных на 64-битные платформы. Практическая значимость. На основе сформулированных правил
реализован программный комплекс Viva64, подтверждающий применимость данных правил. С помощью него возможно автоматизировать процесс поиска ошибок в программах при разработке 64-битных версий приложений. Это позволяет выпускать новые 64-битные программы, во-первых, значительно быстрее, а, во-вторых, со значительно более высоким уровнем качества. На разработанный программный продукт получено свидетельство об официальной регистрации программы для ЭВМ.
Апробация работы. Основные результаты работы докладывались на конференциях: 1. Software Engineering Conference (Russia), 1-2 ноября 2007 г., Москва. 2. Технологии Microsoft в теории и практике программирования, 1-2 апреля 2008 г., Москва. 3. Ломоносов - 2008: Международная конференция студентов, аспирантов и молодых ученых, 7-11 апреля 2008 г., Москва. 4. Междз'народная молодежная научная конференция «XXXIV Гагаринские чтения», 2008 г, Москва. 5. Всероссийская студенческая олимпиада «Конкурс компьютерных программ», 22-23 мая 2008 г., Вологда. 6. Математические методы в технике и технологиях- ММТТ-21, 27-31 мая 2008 г., Саратов. Работа обсуждалась на плановых семинарах: в Тульском государственном университете, кафедра автоматики и телемеханики, Тула, 29 марта 2007 г., 27 февраля 2009 г.; в Вычислительном центре Российской академии наук, отдел систем математического обеспечения, Москва, 15 мая 2008 г.; в Институте системного программирования Российской академии наук, отдел «Технологий программирования», Москва, 7 июня 2008 г., в
Научно-исследовательском вычислительном центре Московского государственного университета, Москва, 23 марта 2009 г.
Структура и объем работы. Диссертационная работа состоит из введения, четырех глаз, заключения и списка литературы. Объем работы составляет 135 страниц. Работа содержит 6 таблиц, 25 рисунков. Список литературы состоит из 102 наименований.
Динамический анализ кода
Для определенного числа пользовательских повседневных программ перенос их в данный момент на 64-битную платформу не даёт какого-либо качественного скачка в производительности. Однако существует ряд областей, где такой скачок будет весьма сильным: программы для работы с базами данных (причём, чем больше объём используемых данных, тем более заметен выигрыш), программы для CAD/CAE (автоматизированное проектирование, моделирование), а также программы для создания цифрового контента (обработка изображений, звука, видео), 3D моделирования (рендеринг, анимация), в том числе высокотехнологичные игры, пакеты научных и высокопроизводительных вычислений (газовая и гидродинамика, сейсмология, геологоразведка, молекулярная химия и биология, генетика, исследования в области нанотехнологий), криптографические программы и экспертные системы и т.д.
Несмотря на некоторую осторожность производителей программного обеспечения в вопросе перехода на 64-битную платформу, под нее выпущено уже достаточно много продуктов. Тем не менее, следует отметить, что указанная инертность программных производителей дает шанс начинающим компаниям не только занять определенное положение на рынке 64-битного программного обеспечения, но и вырваться вперед, в случае интенсивных продвижений версий своих приложений под 64-битные платформы.
Традиционные 32-битные приложения уже начинают достигать предела своих возможностей по использованию оперативной памяти. В Windows-системах для пользовательского приложения доступно два гигабайта памяти (в некоторых случаях три), в то время как для повышения производительности программ в оперативной памяти уже необходимо хранить больше данных. Так, ограничения на память заставляют любителей компьютерных игр все чаще и чаще ждать дозагрузки частей одного уровня, что значительно снижает «эффект присутствия». Пользователи, обрабатывающие видеоизображения, вынуждены обрабатывать кадры с жесткого диска, вместо того, чтобы хранить все данные в быстрой оперативной памяти. Наконец, ученые для своей научной работы (моделирование, визуализация) должны ограничиваться областями минимального размера. Ведь моделировать области большой размерности со скоростью, адекватной задаче, можно лишь храня данные в оперативной памяти машины. И это уже не говоря о задачах, для решения которых необходимо использовать базы данных!
Наметившийся в конце прошлого века кризис в программном мире необходимо было как-то разрешить. Из истории человечества известны два способа развития: эволюционный и революционный. Разумеется, все ждут революции, которая позволит программистам не заботиться о размере оперативной памяти, скорости расчета и других вещах, игнорирование которых приводит к программам-монстрам. Однако, дата следующей компьютерной революции пока неизвестна, а проблему решать надо уже сегодня (точнее даже «вчера»). Властелины компьютерного мира в лице компаний AMD и Intel предложили эволюционное увеличение разрядности машины. Вместо 32-битной архитектуры нам предложили 64-битную. Другими словами, для адресации ячейки оперативной памяти используются не 32-битные числа, а 64-битные. Это приводит к увеличению количества максимально доступной памяти до немыслимых пока значений. Такой вариант развития не является новым в компьютерном мире. Программисты постарше застали переход от 16-битного программного обеспечения к 32-битному, который начался при появлении процессора Intel 80386. Инженеры
AMD и Intel решили повторить успех прошлого, увеличив адресное пространство и количество регистров процессора. В результате, проблемы современных компьютеров хоть и не были решены принципиально, но, в тоже время, необходимость их срочного решения была отложена.
Что же получили программисты с приходом 64-битных систем? Помимо многочисленных преимуществ, о которых написаны сотни и тысячи рекламных статей, программисты получили целый набор задачек, головоломок и даже ловушек, с которыми предстоит столкнуться всем, кто хочет получить реальные преимущества от переноса кода на 64-битные системы.
Когда мы говорим о реальных преимуществах, прежде всего мы имеем в виду доступную оперативную память. Если программа может использовать 64-битное адресное пространство, то это не значит, что конкретная программа написана именно таким образом. Что означает последняя фраза? Всего лишь то, что программа должна быть корректно написана (или перенесена с 32 бит) с учетом поддержки 64-битных систем.
Крупные производители средств разработки пытаются в определенной степени облегчить труд программистов за счет нахождения компилятором некоторых ошибок, связанных с использованием 64 бит. Основная часть доступной документации, выпускаемой этими производителями, утверждает, что, за редким исключением, перекомпиляции и исправления найденных средством разработки ошибок будет достаточно для правильной работы приложения под 64-битной системой. Однако практика показывает, что такие "автоматически отлавливаемые" ошибки - это только надводная часть айсберга, и, в действительности, проблем при переносе возникает намного больше [13, 47, 50, 53].
Разработка статического анализатора: требования, архитектура, реализация
После завершения работы модуля семантического анализа вся возможная информация о программе становится доступной для дальнейшей обработки.
Система диагностики ошибок Говоря об обработке ошибок, разработчики компиляторов имеют в виду особенности поведения компилятора при обнаружении некорректных кодов программ [37, 90]. В этом смысле ошибки можно разделить на несколько типов [39, 101]: лексические - неверно записанные идентификаторы, ключевые слова или операторы; синтаксические - например, арифметические выражения с несбалансированными скобками; семантические - такие как операторы, применяемые с несовместимыми с ними операндами.
Все эти типы ошибок означают, что вместо корректной с точки зрения языка программирования программы на вход компилятору подали некорректную программу. И задача компилятора состоит в том, чтобы, во-первых, диагностировать ошибку, а, во-вторых, по возможности продолжить работу по трансляции или остановиться.
Совсем другой подход к ошибкам возникает, если мы говорим о статическом анализе исходных кодов программ с целью выявления потенциально опасных синтаксических конструкций. Основное отличие заключается в том, что на вход синтаксического анализатора кода подается лексически, синтаксически и семантически абсолютно корректный программный код. Поэтому реализовывать систему диагностики некорректных конструкций в статическом анализаторе так же, как и систему диагностики ошибок в традиционном компиляторе, к сожалению, нельзя.
Реализация анализатора кода состоит из реализации двух частей: компилятора переднего плана (front end compiler); подсистемы диагностики потенциально опасных конструкций. Для реализации компилятора переднего плана будем использовать существующую открытую библиотеку анализа Си++ кода ОрепС++, точнее ее модификацию VivaCore [35], созданную компанией ООО «СиПроВер». Это рукописный синтаксический анализатор кода, в котором осуществляется анализ методом рекурсивного спуска (рекурсивный нисходящий анализ) с возвратом. Выбор рукописного анализатора обусловлен сложностью языка Си++ и отсутствием готовых описанных грамматик этого языка для использования средств автоматического создания анализаторов кода типа YACC и Bison. Для реализации подсистемы поиска потенциально опасных конструкций, как уже было сказано ранее, использовать традиционную для компиляторов систему диагностики ошибок нельзя. Используем для этого несколько приемов по модификации базовой грамматики языка Си++.
Прежде всего, необходимо поправить описание базовых типов языка Си++. Забегая вперед, введем понятие memsize-типов, то есть типов переменной размерности. Все данные типы в программах будем обрабатывать как один специальный тип (memsize). Другими словами, все реальные типы данных, важные с точки зрения переноса кода на 64-битные системы, в коде программ (например, ptrdifft, size_t, void и др.) будут обрабатываться как один тип.
Далее необходимо внести расширение в понятие грамматики, добавив в ее правила вывода символы-действия [5]. Тогда процедура рекурсивного спуска, которая выполняет синтаксический анализ, также будет выполнять некоторые дополнительные действия по проверке семантики. Именно эти дополнительные действия и составляют суть статического анализатора кода. Например, фрагмент грамматики для проверки корректности использования виртуальных функций может выглядеть так: ЗАГОЛОВОК_ВИРТУАЛЬНОЙ_ФУШІДТ4И - virtual ЗАГОЛОВОК_ФУНКЦИИ CheckVirtual() Здесь CheckVirtual() - это тот самый символ-действие. Действие CheckVirtual() будет вызвано, как только процедура рекурсивного спуска обнаружит объявление виртуальной функции в анализируемом коде. А уже внутри процедуры CheckVirtual() будет осуществляться проверка корректности аргументов в объявлении виртуальной функции. Проверки всех потенциально опасных конструкций в языках Си и Си++ с точки зрения переноса кода на 64-битные системы, оформлены в аналогичные символы-действия. Сами эти символы-действия добавлены в грамматику языка, точнее в синтаксический анализатор, который вызывает символы-действия при разборе кода программы.
Виртуальные функции с аргументами THnamemsize
Процессоры работают эффективнее, когда имеют дело с правильно выровненными данными. Как правило, 32-битный элемент данных должен быть выровнен по границе, кратной 4 байт, а 64-битный элемент - по границе 8 байт. Попытка работать с не выровненными данными на процессорах IA 82 (Itanium), как показано в следующем примере, приведет к возникновению исключения:
На архитектуре х64, при обращении к не выровненным данным, исключения не возникает, но их также следует избегать. Во-первых, из-за существенного замедления скорости доступа к таким данным, а во-вторых, из-за высокой вероятности переноса программы в будущем на платформу IA-64. Рассмотрим еще один пример кода, не учитывающий выравнивание данных: struct MyPointersArray { DWORD m_n; PVOID m_arr[l] ; } object; malloc( sizeof(DWORD) + 5 sizeof(PVOID) ); Если мы хотим выделить объем памяти, необходимый для хранения объекта типа MyPointersArray, содержащего 5 указателей, то мы должны учесть, что начало массива m_arr будет выровнено по границе 8 байт. Расположение данных в памяти на разных системах (Win32/Win64) показано на рисунке 12. bytes (32 toils)
В приведенном коде мы узнаем смещение последнего члена структуры и суммируем это смещение с его размером. Смещение члена структуры или класса можно узнать с использованием макроса offsetof или FIELD_OFFSET.
Всегда надо использовать эти макросы для получения смещения в структуре, не опираясь на знание размеров типов и выравнивания. Пример кода с правильным вычислением адреса члена структуры:
Генерирование и обработка исключений с участием целочисленных типов не является хорошей практикой программирования на языке Си++. Для этих целей следует использовать более информативные типы, например классы, производные от классов std::exception. Но иногда все-таки приходится работать с менее качественным кодом, таким как показано ниже:
Разрабатывая 64-битное приложение, надо помнить об изменениях среды, в которой оно теперь будет выполняться. Часть функций станут устаревшими, их будет необходимо изменить на обновленные варианты. Примером такой функции в ОС Windows будет GetWindowLong. Надо обращать внимание на константы, относящиеся к взаимодействию со средой, в которой выполняется программа. В Windows подозрительными будут являться строки, содержащие "system32" или "Program Files".
Явные приведения типов могут изменить логику выполнения программы при изменении разрядности типов или спровоцировать потерю значащих битов. Привести типовые примеры ошибок, связанных с явным приведением типов сложно, так как они очень разнообразны и специфичны для разных программ
Прежде чем говорить о каких-либо правилах диагностики потенциально опасных конструкций, необходимо определится с архитектурой, для которой будут разрабатываться правила. Для нас наиболее важна такая составляющая архитектуры, как модель данных. Модель данных - это соотношение размеров основных типов данных на конкретной архитектуре. Так, модель данных 64-битной архитектуры Windows называется LLP64 [78, 80]. В то время как для 64-битной архитектуры Linux применяется модель LP64 [62, 72]. В дальнейшем все правила будут приводиться для архитектуры LLP64, однако они абсолютно также применимы и к архитектуре LP64 после замены определений основных базовых типов. Введем множество Т- множество всех целочисленных базовых и производных от них типов языка Си++, в том числе указателей. Примеры int, bool, short int, size_t, void , указатели на классы.
Сравнение диагностических возможностей современных анализаторов при проверке 64-битного кода
В целом можно утверждать, что использование Viva64 позволит сократить время выпуска на рынок 64-битных приложений в несколько раз. Это происходит за счет автоматического обнаружения всех потенциально опасных мест в программах, для поиска которых вручную разработчик затратил бы значительно больше времени.
Кроме того, Viva64 обеспечивает значительно более высокое качество приложения. Ведь при анализе кода вручную, без использования Viva64, разработчик вполне может пропустить некоторые ошибки из-за невнимательности. Предлагаемый продукт Viva64 позволяет избежать этого.
Цель данного раздела - продемонстрировать преимущества анализатора Viva64 по сравнению с другими продуктами, обладающими схожими функциональными возможностями. Актуальность раздела заключается в отсутствии систематизированной информации о возможностях современных статических анализаторов, которые заявлены как средства диагностики 64-битных ошибок. Будет выполнено сравнение трех наиболее распространенных анализаторов, реализующих проверки 64-битного кода: Viva64, Parasoft C++Test, Gimpel Software PC-Lint.
Приступим непосредственно к сравнению статических анализаторов. Сравнительная информация представлена в таблице. Список критериев оценки был составлен на основе документации к статическим анализаторам [57, 82, 98], статьям [13] и другим дополнительным ресурсам.
Указанные в таблице критерии оценок - это все потенциальные ошибки, перечисленные в разделе 3.1. Напротив каждого типа ошибки указано «Да», если тот или иной анализатор обнаруживает ее в коде и «Нет», если не обнаруживает. Из рисунка видно, что разработанный программный продукт Viva64 превосходит аналоги по количеству диагностируемых ошибок.
Об эффективности использования статических анализаторов говорить сложно. Безусловно, методология статического анализа крайне полезна и позволяет обнаруживать большое количество ошибок еще на этапе написания кода, что существенно сокращает этап отладки и тестирования.
Но следует понимать, что статический анализ никогда не позволит выловить все ошибки, даже в конкретной области, которой является анализ 64-битного кода. Перечислим основные причины: 1. Некоторые элементы языка Си++ затруднены для анализа. В первую очередь это касается кода шаблонов, так как они оперируют с различными типами данных одними и теми же конструкциями. 2. Ошибки при переносе 32-битной программы на 64-битную систему могут содержаться не только в коде, но и быть косвенными. Хорошим примером может служить размер стека, который по умолчанию не изменяет в Visual Studio 2005/2008 при сборке 64-битной версии проекта и равняется 1 мегабайту. При работе 64-битный код может значительно больше заполнять стек, чем 32-битный код. Это связано с ростом размеров указателей и других объектов, другим выравниванием. В результате 64-битной сборке программы может неожиданно не хватить стека во время работы. 3. Существуют ошибки алгоритмического характера, возникшие из некоторых предположений относительно размерностей типов, которые изменяются в 64-битной системе. 4. Ошибки могут крыться в сторонних 64-битных библиотеках. Перечисленный список не полон, но позволяет утверждать, что некоторые ошибки могут быть обнаружены только при запуске программы. Другими словами необходимо нагрузочное тестирование приложений, использование динамических систем анализа (например, Compuware Bounds Checker), юнит-тестирование, ручное тестирование и так далее.
Таким образом, гарантию качества 64-битной программы может дать только комплексный подход к ее проверке, когда используются различные методологии и инструменты.
Следует также понимать, что приведенная выше критика не снижает пользу от использования статического анализа. Статический анализ является самым эффективным методом обнаружения ошибок при переносе 32-битного кода на 64-битные системы. Он позволяет отловить большинство ошибок за сравнительно короткое время. К преимуществам статического анализа кода можно отнести: 1. Возможность проверить все ветви кода, не зависимо от частоты их выполнения в реальных условиях. 2. Возможность выполнить проверку еще на этапе переноса или разработки кода. Тем самым огромное количество ошибок исправляется еще до этапа тестирования и отладки. Это существенно экономит ресурсы и время. Общеизвестно, что чем раньше обнаружена ошибка, тем дешевле обходится ее исправление. 3. Статический анализатор умеет обнаруживать опасные конструкции, которые программист склонен считать корректными, так как они показали свою работоспособность на 32-битных системах. 4. Статический анализ позволяет заранее оценить качество кода с точки зрения его корректности для 64-битных систем и тем самым лучше спланировать ход работ.
В диагностике 64-битного кода для операционной системы Windows лидирует специализированный анализатор Viva64. В первую очередь это связано с тем, что он ориентирован на модель данных LLP64, а во вторую тем, что в нем реализованы новые специфические правила диагностики.
В диагностике 64-битного кода для операционных систем семейства Unix следует отдать предпочтение анализатору общего назначения PC-Lint. По сравнительной таблице его лидерство не очень заметно, но он реализует более важные правила, по сравнению с C++Test.
