Linux программирование в примерах

• Помимо инструментов отладки, неотъемлемой частью процесса разработки программного обеспечения является также тестирование программ. Ее следует понять, запланировать и управлять ею с самого начала любого проекта разработки программного обеспечения, даже индивидуального.

• Отладка является умением, которому можно научиться. Мы рекомендуем прочесть книгу Debugging Дэвида Дж. Эганса и научиться применять его правила.

Упражнения

1. Откомпилируйте одну из ваших программ с помощью GCC, используя как -g, так и -O. Запустите ее под GDB, установив контрольную точку в main(). Выполните программу пошагово и посмотрите, насколько близко соответствует (или не соответствует) исполнение оригинальному исходному коду. Это особенно хорошо делать с кодом, использующим циклы while или for.

2. Прочитайте об особенности GDB условной контрольной точки. Насколько это упрощает работу с проблемами, которые появляются лишь после того, как будет сделано определенное число операций?

3. Перепишите функцию parse_debug() из раздела 15.4.2.1 «Добавляйте отладочные опции и переменные», чтобы использовать таблицу строк опций отладки, значений флагов и длин строк

4. (Трудное.) Изучите исходный код gawk; в частности, структуру NODE в awk.h. Напишите вспомогательную отладочную функцию, которая выводит содержимое NODE, основываясь на значении в поле type.

5. Возьмите одну из своих программ и измените ее так, чтобы использовать библиотеку dbug. Откомпилируйте ее сначала без -DDBUG, чтобы убедиться, что она компилируется и работает нормально. (Есть ли у вас для нее набор возвратных тестов? Прошла ли ваша программа все тесты?)

Убедившись, что добавление библиотеки dbug не нарушает работу вашей программы, перекомпилируйте ее с -DDBUG. По-прежнему ли проходит ваша программа все свои тесты? Какова разница в производительности при включенной и отключенной библиотеке? Запустите ваш тестовый набор с опцией -#t, чтобы увидеть трассировку вызовов функций. Как вы думаете, это поможет вам в будущем, когда придется иметь дело с отладкой? Почему да или почему нет?

6. Запустите одну из своих программ, использующих динамическую память, с Electric Fence или одним из других тестеров динамической памяти. Опишите проблемы, которые вы обнаружили, если они есть.

7. Перезапустите ту же самую программу, используя Valgrind с включенным режимом проверки утечек. Опишите найденные вами проблемы, если они есть.

8. Разработайте набор тестов для программы mv. (Прочтите mv(1): убедитесь, что охватили все ее опции.)

9. Поищите в Интернете ресурсы по тестированию программного обеспечения. Какие интересные вещи вы нашли?

Глава 16 Проект, связывающий все воедино

В первой половине этой книги мы довольно аккуратно связали все, что было представлено, рассмотрев V7 ls.c. Однако, нет достаточно небольшой программы, насколько бы это нам хотелось, чтобы связать воедино все концепции и API, представленные начиная с главы 8 «Файловые системы и обходы каталогов».

16.1. Описание проекта

В повседневном использовании единственной программой, которая действительно использует почти все в этой книге, является оболочка. И на самом деле есть книги по программированию на Unix, в которых пишется небольшая, но работающая оболочка для иллюстрации использованных принципов.

Настоящие оболочки являются большими и беспорядочными творениями. Они должны иметь дело со многими проблемами переносимости, такими, которые мы обрисовывали по всей книге, а помимо этого, они часто должны обходить различные ошибки в различных версиях Unix Более того, чтобы быть полезными, оболочки делают множество вещей, которые не затрагивают API системных вызовов, такие, как хранение переменных оболочки, историю сохраненных команд и т.д. Предоставление завершенного обзора полноценной оболочки, такой как Bash, ksh93 или zsh, потребовало бы отдельной книги.

Вместо этого мы рекомендуем следующий список шагов по написанию своей собственной оболочки либо в качестве (большого) упражнения для закрепления вашего понимания, либо, возможно, в качестве совместного проекта, если вы обучаетесь в учебном заведении.

1. Спроектируйте свой командный «язык», чтобы его было легко интерпретировать с помощью простого кода. Хотя технология компиляторов и интерпретаторов полезна при написании оболочки как изделия, для вас на данный момент это, вероятно, излишне.

Рассмотрите следующие моменты:

 • Собираетесь ли вы использовать возможности интернационализации?

 • Какие команды должны быть встроены в оболочку?

 • Чтобы быть полезной, в вашей оболочке должен быть механизм пути поиска команд, аналогичный $PATH в обычной оболочке. Как вы его установите?

 • Какие перенаправления ввода/вывода вы хотите поддержать? Только файлы? Также и каналы? Хотите ли вы иметь возможность перенаправлять нет только дескрипторы файлов 0, 1 и 2?