Марк Митчелл - Программирование для Linux. Профессиональный подход
Вероятнее всего, для программы потребуется создать man-страницу. Это первое место, куда пользователи обращаются за информацией о программе. Страницы интерактивной документации форматируются с помощью классической программы troff. Чтобы узнать формат troff-файлов, введите такую команду:
% man troff
Чтобы узнать, как ОС Linux ищет man-страницы, просмотрите справочную информацию о самой команде man:
% man man
Можно также подготовить документацию в формате GNU-системы Info. Для получения информацию об этой системе выполните команду
% info info
Для многих Linux-лрограмм имеется также документация в формате простого текста и HTML.
Удачного программирования!
Часть III
Приложения
Приложение А
Вспомогательные инструменты разработки
Разработка безошибочных и быстрых Linux-программ требует не только понимания операционной системы Linux и ее системных вызовов. В этом приложении будут рассмотрены методики, позволяющие находить ошибки периода выполнения (например, неправильное использование оперативной памяти) и определять, какие компоненты программы требуют наибольших вычислительных ресурсов. Анализ программного кода дает лишь часть этой информации; чтобы получить остальную часть, необходимо запустить программу и воспользоваться описанными ниже инструментами.
А.1. Статический анализ программы
Некоторые программные ошибки можно выявить, воспользовавшись средствами статического анализа исходных текстов. Если вызвать компилятор gcc с флагами -Wall и -pedantic, он выдаст предупреждения о рискованных и потенциально ошибочных программных конструкциях. Исправив эти конструкции, вы снизите вероятность появления в программе скрытых ошибок, а также упростите компиляцию программы в других вариантах Linux или даже в других операционных системах.
С помощью различных флагов командной строки можно заставить компилятор gcc выдавать предупреждения о множестве спорных программных конструкций. Большинство проверок включается флагом -Wall. Например, компилятор будет сообщать о комментарии, начинающемся в другом комментарии, о неправильном типе возвращаемого значении в функции main(), о функциях, в которых пропущена инструкция return, и т.д. При наличии флага -pedantic компилятор будет выдавать предупреждения о несоответствии стандарту ANSI. В частности, будет сообщаться о наличии функции asm() и других GNU-расширений языка. В документации к компилятору не рекомендуется использовать этот флаг. Мы же советуем избегать большинства GNU-расширений, так как они имеют тенденцию меняться со временем и плохо поддаются оптимизации.
Попробуем скомпилировать программу "Hello, World", представленную в листинге А.1.
Листинг А.1. (hello.c) Простейшая программаmain() {
printf("Hello, world.n");
}
Будучи вызванным без флагов, компилятор не выдаст никаких предупреждений, хотя программа не соответствует стандарту ANSI Если же включить флаги -Wall и -pedantic, то обнаружатся три спорные конструкции:
% gcc -Wall -pedantic hello.c
hello.c:2: warning: return type defaults to 'int'
hello.c: In function 'main':
hello.c:3: warning: implicit declaration of function 'printf'
hello.c:4: warning: control reaches end of non-void function
Компилятор сообщает о следующих проблемах:
■ не указан тип возвращаемого значения функции main();
■ функция printf() не объявлена, так как файл <stdio.h> не включен в программу;
■ функция main(), которая неявно возвращает значение типа int, не содержит инструкцию return.
Анализ исходных текстов программы не позволяет выявить все возможные ошибки и неэффективные конструкции. В следующем разделе описываются четыре средства поиска ошибок при работе с динамической памятью. В конце приложения будет рассказано о том, как анализировать время работы программы с помощью утилиты-профайлера gprof.
А.2. Поиск ошибок в динамической памяти
При написании программы зачастую неизвестно, сколько памяти потребуется ей во время выполнения. Например, строка, читаемая из файла, может иметь любую длину. Работа с динамической памятью осуществляется посредством функций malloc(), free() и их вариантов. Следует придерживаться таких правил:
■ число запросов на выделение памяти (вызовов функции malloc()) должно в точности совпадать с чистом запросов на освобождение памяти (вызовов функции free());
■ операции чтения и записи динамической памяти должны выполняться в рамках выделенной области, не выходя за ее пределы;
■ к выделенной области нельзя обращаться после того, как она была освобождена.
Выделение и освобождение динамической памяти происходят на этапе выполнения программы, поэтому статический анализ исходных текстов редко позволяет выявить недочеты. Утилиты проверки памяти сначала загружают программу, а затем определяют, нарушаются ли перечисленные выше правила. Выявляются следующие ошибки:
■ чтение памяти до того, как она была выделена;
■ запись в память до того, как она была выделена;
■ чтение данных по адресу, предшествующему началу выделенной области;
■ запись данных по адресу, предшествующему началу выделенной области;
■ чтение данных по адресу, стоящее после выделенной области;
■ запись данных по адресу, стоящему после выделенной области;
■ чтение памяти после того, как она была освобождена;
■ запись в память после того, как она была освобождена;
■ неудачная попытка освободить выделенную память;
■ попытка повторно освободить ту же самую область памяти;
■ попытка освободить память, которая не была выделена.
Полезно также предупреждать о выделениях областей размером 0 байтов, так как это обычно свидетельствует об ошибке программиста.
В табл. А.1 описаны возможности четырех диагностических средств. К сожалению, ни одно из них не выявляет все возможные ошибки. Кроме того, ни одно средство не позволяет обнаруживать попытки чтения или записи памяти до того, как она была выделена, хотя такая попытка наверняка приведет к нарушению сегментации. Обнаруживаются те ошибки, которые действительно происходят в процессе работы программы. Если передать программе такие входные данные, что выделять память не понадобится, ошибки обращения к памяти не будут найдены. Для максимально тщательной проверки программы рекомендуется передавать ей самые разные входные данные, чтобы протестировать все возможные пути ее выполнения. Желательно также тестировать программу всеми имеющимися средствами.
Таблица А.1. Возможности средств проверки динамической памяти (X — обнаружение, О — обнаружение в некоторых случаях):
Ошибка Проверка функции malloc() Утилита mtrace Библиотека ccmalloc Библиотека Electric Fence Чтение памяти до того, как она была выделена Запись в память до того, как она была выделена Чтение данных по адресу, предшествующему началу выделенной области X Запись данных по адресу, предшествующему началу выделенной области О О X Чтение данных по адресу, стоящему после выделенной области X Запись данных по адресу, стоящему после выделенной области X X Чтение памяти после того, как она была освобождена X Запись в память после того, как она была освобождена X Неудачная попытка освободить выделенную память X X Попытка повторно освободить ту же самую область памяти X X Попытка освободить память. которая не была выделена X X Выделение памяти нулевого размера X XА.2.1. Программа для тестирования динамической памяти
