Linux программирование в примерах [Арнольд Роббинс] (fb2) читать онлайн


 [Настройки текста]  [Cбросить фильтры]
  [Оглавление]

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

Предисловие

Одним из лучших способов научиться программированию является чтение хорошо написанных программ. Данная книга обучает фундаментальному API системных вызовов Linux — тех, которые образуют ядро любой значительной программы — представляя код из программных изделий, которые вы используете каждый день.

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

Хотя книга называется Программирование под Linux на примерах, все, что мы рассматриваем, относится также к современным системам Unix, если не отмечено противное. Обычно мы используем термин «Linux» для обозначения ядра Linux, a «GNU/Linux» для обозначения всей системы (ядра, библиотек, инструментов). Часто также мы говорим «Linux», когда имеем в виду и Linux, GNU/Linux и Unix; если что-то является специфичным для той или иной системы, мы отмечаем это явным образом.

Аудитория
Данная книга предназначена для лиц, разбирающихся в программировании и знакомых с основами С, по крайней мере на уровне книги Кернигана и Ричи Программирование на языке С. (Программисты Java, желающие прочесть эту книгу, должны разбираться в указателях С, поскольку С активно их использует.) В примерах используются как версия Стандартного С 1990 года, так и Оригинальный С.

В частности, вам следует быть знакомыми со всеми операторами С, структурами управления потоком исполнения, использованием объявлений переменных и указателей, функциями работы со строками, использованием exit() и набором функций <stdio.h> для файлового ввода/вывода.

Вы должны понимать базовые концепции стандартного ввода, стандартного вывода и стандартной ошибки, а также знать тот факт, что все программы на С получают массив символьных строк, представляющих вызываемые опции и аргументы. Вы должны также быть знакомы с основными инструментами командной строки, такими, как cd, cp, date, ln, ls, maninfo, если он у вас имеется), rmdir и rm, с использованием длинных и коротких опций командной строки, переменных окружения и перенаправления ввода/вывода, включая каналы.

Мы предполагаем, что вы хотите писать программы, которые работают не только под GNU/Linux, но и на множестве различных систем Unix. С этой целью мы помечаем каждый интерфейс с точки зрения его доступности (лишь для систем GLIBC или определен в POSIX и т.д.), а в тексте приведены также советы по переносимости.

Программирование, которое здесь приводится, может быть на более низком уровне, чем вы обычно использовали; это нормально. Системные вызовы являются основными строительными блоками для операций более высокого уровня и поэтому они низкоуровневые по своей природе. Это, в свою очередь, определяет использование нами С: функции API были спроектированы для использования из С, и код, связывающий их с языками более высокого уровня, такими как C++ и Java, неизбежно будет на более низком уровне и вероятнее всего, написанным на С. «Низкий уровень» не означает «плохой», это просто значит «более стимулирующий».

Что вы изучите
Данная книга фокусируется на базовых API, образующих ядро программирования под Linux:

• Управление памятью

• Файловый ввод/вывод

• Метаданные файлов

• Процессы и сигналы

• Пользователи и группы

• Поддержка программирования (сортировка, анализ аргументов и т.д.)

• Интернационализация

• Отладка

Мы намеренно сохранили список тем коротким. Мы считаем, что попытка научить а одной книге «всему, что можно узнать», пугает. Большинство читателей предпочитают книжки поменьше, более сфокусированные, и лучшие книги по Unix написаны таким способом

Поэтому вместо одного гигантского тома мы планируем несколько книг: одну по межпроцессному взаимодействию (IPC) и сетям, другую по разработке программного обеспечения и переносимости кода. Мы также положили глаз а направлении дополнительных томов в серии Программирование под Linux на примерах, которые будут раскрывать такие темы, как многопоточное программирование и программирование графических интерфейсов пользователя (GUI).

Рассматриваемые нами API включают как системные вызовы, так и библиотечные функции. Действительно, на уровне С оба вида выступают в виде простых вызовов функций. Системный вызов является непосредственным запросом системной службы, такой, как чтение или запись файла или создание процесса. Библиотечная функция, с другой стороны, работает на уровне пользователя, возможно, никогда не запрашивая какие-либо сервисы у операционной системы. Системные вызовы документированы в разделе 2 справочного руководства (которое можно просмотреть с помощью команды man), а библиотечные функции документированы в разделе 3.

Нашей целью является научить вас использовать Linux API на примерах: в частности, посредством использования, где это возможно, как оригинальных исходных кодов Unix, так и инструментов GNU. К сожалению, самодостаточных примеров не так много, как должно было бы быть. Поэтому мы также написали большое число небольших демонстрационных программ. Был сделан акцент на принципах программирования: особенно на таких аспектах программирования для GNU, как «никаких произвольных ограничений», которые превращают инструменты GNU в незаурядные программы.

Выбор для изучения повседневных программ намеренный. Если вы уже использовали GNU/Linux в течение какого-либо периода времени, вы уже понимаете, что делают такие программы, как ls и cp; после этого просто погрузиться прямо в то, как работают программы, не тратя много времени на изучение того, что они делают.

Иногда мы представляем как высокоуровневый, так и низкоуровневый способы выполнения задачи. Обычно стандарт интерфейса более высокого уровня реализуется посредством более низкоуровневого интерфейса или конструкции. Мы надеемся, что такой взгляд на то, что происходит «под капотом», поможет вам понять, как это работает; для всего кода, который вы пишете сами, нужно всегда использовать более высокоуровневый, стандартный интерфейс.

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

Наконец, каждая глава завершается упражнениями. Некоторые из них требуют модификации или написания кода. Другие больше относятся к категориям «Мысленных экспериментов» или «как вы думаете, почему…». Мы рекомендуем выполнить их все — они помогут закрепить понимание материала.

Небольшой — значит красивый: программы Unix
Закон Хоара: «Внутри каждой большой программы есть старающаяся пробиться маленькая программа»

- C.A.R. Hoare -
Вначале мы планировали обучать Linux API, используя код инструментов GNU. Однако, современные версии даже простых программ командной строки (подобно mv и cp) большие и многофункциональные. Это особенно верно в отношении GNU вариантов стандартных утилит, которые допускают длинные и короткие опции, делают все, требуемое POSIX и часто имеют также дополнительные, внешне не связанные опции (подобно выделению вывода).

Поэтому возник разумный вопрос: «Как мы можем в этом большом и запутывающем лесу сконцентрироваться на одном или двух важных деревьях?» Другими словами, если мы представим современные полнофункциональные программы, будет ли возможно увидеть лежащую в основе работу программы?

Вот когда закон Хоара[1] вдохновил нас на рассмотрение в качестве примера кода оригинальных программ Unix. Оригинальные утилиты V7 Unix маленькие и простые, что упрощает наблюдение происходящего и понимание использования системных вызовов (V7 был выпущен около 1979 г.; это общий предок всех современных систем Unix, включая системы GNU/Linux и BSD.)

В течение многих лет исходный код Unix был защищен авторскими правами и лицензионными соглашениями коммерческой тайны, что затрудняло его использование для обучения и делало невозможным опубликование. Это до сих пор верно в отношении исходного кода всех коммерческих систем Unix. Однако в 2002 г. Caldera (в настоящее время работающая под именем SCO) сделала оригинальный код Unix (вплоть до V7 и 32V Unix) доступным на условиях лицензии в стиле Open Source (см. приложение В «Лицензия Caldera для старой Unix»). Это дает нам возможность включить в эту книгу код из ранних систем Unix.

Стандарты
По всей книге мы ссылаемся на несколько различных официальных стандартов. Стандарт является документом, описывающим, как что-либо работает. Официальные стандарты существуют для многих вещей, например, форма, размещение и назначение отверстий в электрической розетке на вашей стене определяется официальным стандартом, так что все сетевые шнуры в вашей стране работают со всеми розетками.

Таким же образом официальные стандарты для вычислительных систем определяют, как они должны работать; это дает возможность пользователям и разработчикам знать, чего ожидать от своего программного обеспечения, и дает им возможность жаловаться своему поставщику, когда программное обеспечение не работает.

Здесь интерес для нас представляют:

1. ISO/IEC International Standard 9899 Programming Languages — С (Международный стандарт ISO/IEC 9899. Языки программирования - С), 1990. Первый официальный стандарт для языка программирования С.

2. ISO/IEC International Standard 9899. Programming Languages — С, Second edition, 1999 (Международный стандарт ISO/IEC 9899. Языки программирования С, второе издание). Второй (текущий) официальный стандарт для языка программирования C.

3. ISO/IEC International Standard 14882. Programming Languages — С++, 1998 (Международный стандарт ISO/IEC 14882. Языки программирования - С++). Первый официальный стандарт для языка программирования С++.

4. ISO/IEC International Standard 14882. Programming Languages — С++, 2003 (Международный стандарт 14882. Языки программирования — С++). Второй (текущий) официальный стандарт для языка программирования С++.

5. IEEE Standard 1003 1-2001 Standard for Information Technology — Portable Operating System Interface (POSIX®) (Стандарт IEEE 1003.1-2001. Стандарт информационных технологий — переносимый интерфейс операционной системы). Текущая версия стандарта POSIX; описывает поведение, ожидаемое от Unix и Unix-подобных систем. Данное издание освещает как системные вызовы, так и библиотечные интерфейсы с точки зрения программиста C/C++, и интерфейс оболочки и инструментов с точки зрения пользователя. Он состоит из нескольких томов:

 • Базовые определения (Base Definitions). Определения терминов, средств и заголовочных файлов.

 • Базовые определения — Обоснование (Base Definitions — Rationale). Объяснения и обоснования выбора средств как включенных, так и невключенных в стандарт.

 • Системные интерфейсы (System Interfaces). Системные вызовы и библиотечные функции. POSIX называет обе разновидности просто «функции».

 • Оболочка и инструменты (Shell and Utilities). Язык оболочки и доступные для интерактивного использования и использования сценариями оболочки инструменты.

Хотя стандарты языков не являются захватывающим чтением, можно рассмотреть покупку экземпляра стандарта С, он дает окончательное определение языка. Книги можно приобрести в ANSI[2] и в ISO[3]. (PDF-версия стандарта С вполне доступна.)

Стандарт POSIX можно заказать в The Open Group[4]. Исследуя в каталоге их изданий элементы, перечисленные а «Спецификациях CAE» («CAE Specifications»), вы можете найти отдельные страницы для каждой части стандарта (озаглавленные с «C031» по «C034»). Каждая такая страница предоставляет свободный доступ к HTML версии определенного тома

Стандарт POSIX предназначен для реализации как Unix и Unix-подобных систем, так и не-Unix систем. Таким образом, базовые возможности, которые он предоставляет, составляют лишь часть возможностей, которые есть на системах Unix. Однако, стандарт POSIX определяет также расширения — дополнительные возможности, например, для многопоточности или поддержки реального времени. Для нас важнее всего расширение X/Open System Interface (XSI), описывающее возможности исторических систем Unix.

По всей книге мы помечаем каждый API в отношении его доступности: ISO С, POSIX, XSI, только GLIBC или как нестандартный, но широко доступный.

Возможности и мощь: программы GNU
Ограничив себя лишь оригинальным кодом Unix, можно было бы получить интересную историческую книгу, но она была бы не очень полезна в XXI веке. Современные программы не имеют тех же ограничений (памяти, мощности процессора, дискового пространства и скорости), которые были у ранних систем Unix. Более того, они должны работать в многоязычном мире — ASCII и американского английского недостаточно.

Что еще важнее, одной из главных свобод, выдвинутых явным образом Фондом бесплатных программ (Free Software Foundation) и проектом GNU[5], является «свобода обучения». Программы GNU предназначены для обеспечения большого собрания хорошо написанных программ, которые программисты среднего уровня могут использовать а качестве источника для своего обучения.

Используя программы GNU, мы преследуем две цели: показать вам хорошо написанный современный код, на котором вы будете учиться писать хорошие программы, а также использовать API.

Мы считаем, что программное обеспечение GNU лучше, поскольку оно свободно (в смысле «свободы», а не «бесплатного пива»)[6]. Но признается также, что программное обеспечение GNU часто также технически лучше соответствующих двойников в Unix, и мы уделили место в разделе 1.4 «Почему программы GNU лучше», чтобы это объяснить

Часть примеров кода GNU происходит из gawk (GNU awk). Главной причиной этого является то, что это программа, с которой мы очень знакомы, поэтому было просто отобрать оттуда примеры. У нас нет относительно нее других притязаний.

Обзор глав
Вождение автомобиля целостный процесс, включающий множество одновременных задач. Во многих отношениях программирование по Linux похоже на это, требуя понимания многих аспектов API, таких, как файловый ввод/вывод, метаданные файлов, каталоги, хранение сведений о времени и т.д.

В первой части книги рассматривается достаточное количество этих отдельных элементов, чтобы дать возможность изучить первую значительную программу, V7 ls. Затем мы завершим наше обсуждение файлов и пользователей, рассмотрев иерархии файлов и принципы работы файловых систем и их использование.

Глава 1, «Введение»,

описывает модели файлов и процессов Unix и Linux, рассматривает отличия оригинального С от стандартного С 1990 г., а также предоставляет обзор принципов, которые делают программы GNU в целом лучшими по сравнению со стандартными программами Unix.

Глава 2, «Аргументы, опции и переменные окружения»,

описывает, как С программа получает доступ к аргументам и опциям командной строки и обрабатывает их, а также объясняет, как работать с переменными окружения.

Глава 3, «Управление памятью на уровне пользователя»,

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

Глава 4, «Файлы и файловый ввод/вывод»,

обсуждает базовый файловый ввод/вывод, показывая, как создавать и использовать файлы. Понимание этого важно для всего последующего материала.

Глава 5, «Каталоги и служебные данные файлов»,

описывает, как работают каталоги, прямые и символические ссылки. Затем описываются служебные данные файлов, такие, как владелец, права доступа и т.д., а также освещается работа с каталогами

Глава 6, «Общие библиотечные интерфейсы — часть 1»,

рассматривает первый набор интерфейсов общего программирования, которые будут нам нужны для эффективного использования служебных данных файлов.

Глава 7, «Соединяя все вместе: ls»,

связывает воедино все рассмотренное до сих пор, рассматривая программу V7 ls.

Глава 8, «Файловые системы и обходы каталогов»,

описывает, как монтируются и демонтируются файловые системы и как программа может получить сведения о том, что смонтировано в системе. В главе описывается также, как программа может легко «обойти» всю иерархию файлов, предпринимая а отношении каждого встреченного объекта необходимые действия.

Вторая часть книги имеет дело с созданием и управлением процессами, межпроцессным взаимодействием посредством каналов и сигнала, ID пользователей и групп и дополнительными интерфейсами общего программирования. Далее в книге сначала описываются интернационализация с использованием GNU gettext, а затем несколько расширенных API.

Глава 9, «Управление процессами и каналы»,

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

Глава 10, «Сигналы»,

обсуждает сигналы, упрощенную форму межпроцессного взаимодействия. Сигналы играют также важную роль а управлении родительским процессом порожденных процессов.

Глава 11, «Права доступа и ID пользователей и групп»,

рассматривает, как идентифицируются процессы и файлы, как работает проверка прав доступа и как работают механизмы setuid и setgid.

Глава 12, «Общие библиотечные интерфейсы — часть 2»,

рассматривает оставшуюся часть общих API; многие из них более специализированы, чем первый общий набор API.

Глава 13, «Интернационализация и локализация»,

объясняет, как почти без усилий обеспечить работу ваших программ на нескольких языках.

Глава 14, «Расширенные интерфейсы»,

описывает несколько расширенных версий интерфейсов, освещенных в предыдущих главах, а также более подробно освещает блокировку файлов.

Мы завершаем книгу главой об отладке, поскольку (почти) никто не может сделать все правильно с первого раза, и рекомендуем финальный проект для закрепления ваших знаний по рассмотренным в данной книге API.

Глава 15, «Отладка»,

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

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

представляет значительный проект по программированию, который использует почти все, рассмотренное в книге.

Несколько приложений освещают представляющие интерес темы, включая лицензии для использованного в данной книге исходного коде.

Приложение А, «Научитесь программированию за десять лет»,

ссылается на знаменитое высказывание: «Москва не сразу строилась»[7]. Также и квалификация в Linux/Unix и понимание этих систем приходит лишь со временем и практикой. С этой целью мы включили это эссе Петера Норвига, которое мы горячо рекомендуем.

Приложение В, «Лицензия Caldera для старой Unix»,

охватывает исходный код Unix, использованный в данной книге.

Приложение С, «Общедоступная лицензия GNU»,

охватывает исходный код GNU, использованный в данной книге.

Соглашения об обозначениях
Как и в любой книге на компьютерную тему, для передачи информации мы используем определенные соглашения об обозначениях. Определения или первое использование термина выделяется курсивом, как слово «Определения» в начале этого предложения. Курсив используется также для выделения, для цитирования других работ и комментариев в примерах. Переменные элементы, такие, как аргументы или имена файлов, выглядят таким образом. Иногда мы используем жирный шрифт, когда нужно усилить мысль.

Вещи, находящиеся на компьютере, обозначаются моноширинными шрифтом, как в случае имен файлов (foo.c) и названий команд (ls, grep). Короткие фрагменты, которые вы вводите, дополнительно заключаются в одинарные кавычки: 'ls -l *.с'

$ и > являются первичным и вторичным приглашениями оболочки Борна и используются при отображении интерактивных примеров. Ввод пользователя выделяется другим шрифтом от обычного вывода компьютера в примерах. Примеры выглядят следующим образом:

$ ls -1 /* Просмотр файлов. Опция - цифра 1, а не буква l */

foo

bar

baz

Мы предпочитаем оболочку Борна и ее варианты (ksh93, Bash) по сравнению с оболочкой С; соответственно на всех наших примерах показана лишь оболочка Борна. Знайте, что правила применения кавычек и переноса на следующую строку в оболочке С другие; если вы используете ее, то на свой страх и риск![8]

При ссылках на функции в программах мы добавляем к имени функции пустую пару скобок: printf(), strcpy(). При ссылке на справочную страницу (доступную по команде man), мы следуем стандартному соглашению Unix по написанию имени команды или функции курсивом, а раздела — в скобках после имени обычным шрифтом: awk(1), printf(3)[9].

Где получить исходные коды Unix и GNU
Вы можете захотеть получить копни программ, которые мы использовали в данной книге, для своих собственных экспериментов и просмотра. Весь исходный код доступен через Интернет, а ваш дистрибутив GNU/Linux содержит исходный код для инструментов GNU.

Код Unix
Архивы различных «древних» версий Unix поддерживаются Обществом наследства UNIX (The UNIX Heritage Society — TUHS), http://www.tuhs.org.

Наибольший интерес представляет возможность просматривать архив старых исходных кодов Unix через веб. Начните с http://minnie.tuhs.org/UnixTree/. Все примеры кода в данной книге из седьмого издания исследовательской системы UNIX, известной также как «V7».

Сайт TUHS физически расположен в Австралии, хотя имеются зеркала архива по всему миру — см. http://www.tuhs.org/archive_sites.html. Эта страница также указывает, что архив доступен для зеркала через rsync. (Если у вас нет rsync, см. http://rsync.samba.org/: это стандартная утилита на системах GNU/Linux.)

Чтобы скопировать весь архив, потребуется примерно 2-3 гигабайта дискового пространства. Для копирования архива создайте пустой каталог, а в нем выполните следующие команды:

mkdir Applications 4BSD PDP-11 PDP-11/Trees VAX Other

rsync -avz minnie.tuhs.org::UA_Root .

rsync -avz minnie.tuhs.org::UA_Applications Applications

rsync -avz minnie.tuhs.org::UA_4BSD 4BSD

rsync -avz minnie.tuhs.org::UA_PDP11 PDP-11

rsync -avz minnie.tuhs.org::UA_PDP11_Trees PDP-11/Trees

rsync -avz minnie.tuhs.org::UA_VAX VAX

rsync -avz minnie.tuhs.org::UA_Other Other

Вы можете пропустить копирование каталога Trees, который содержит извлечения из нескольких версий Unix и занимает на диске около 700 мегабайт.

В рассылке TUHS можно также поинтересоваться, нет ли поблизости от вас кого-нибудь, кто мог бы предоставить вам архив на CD-ROM, чтобы избежать пересылки по Интернету такого большого количества данных.

Группа в Southern Storm Software, Pty. Ltd. в Австралии «модернизировала» часть кода уровня пользователя V7, так что его можно откомпилировать и запустить на современных системах, особенно на GNU/Linux. Этот код можно загрузить с их веб-сайта[10].

Интересно отметить, что код V7 не содержит в себе каких-либо уведомлений об авторских правах или разрешениях. Авторы писали код главным образом для себя и своего исследования, оставив проблемы разрешений отделу корпоративного лицензирования AT&T.

Код GNU
Если вы используете GNU/Linux, ваш дистрибутив поступит с исходным кодом, предположительно в формате, используемом для упаковки (файлы RPM Red Hat, файлы DEB Debian, файлы .tar.gz Slackware и т.д.) Многие примеры в книге взяты из GNU Coreutils, версия 5.0. Найдите соответствующий CD-ROM для своего дистрибутива GNU/Linux и используйте для извлечения кода соответствующий инструмент. Или следуйте для получения кода инструкциям в следующих нескольких абзацах.

Если вы предпочитаете самостоятельно получать файлы из ftp-сайта GNU, вы найдете его по адресу: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.gz.

Для получения файла можно использовать утилиту wget:

$ wget ftp://ftp.gnu.org/ena/coreutils/coreuitils-5.0.tar.gz

/* Получить дистрибутив */

/* ... здесь при получении файла куча вывода ... */

В качестве альтернативы можно использовать для получения файла старый добрый ftp:

$ ftp ftp.gnu.org /* Подключиться к ftp-сайту GNU */

Connected to ftp.gnu.org (199.232.41.7).

220 GNU FTP server ready.

Name (ftp.gnu.org:arnold): anonymous /* Использовать анонимный ftp */

331 Please specify the password.

Password: /* Пароль на экране не отображается */

230-If you have any problems with the GNU software or its downloading,

230-please refer your questions to <gnu@gnu.org>.

... /* Куча вывода опущена */

230 Login successful. Have fun.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> cd /gnu/coreutils /* Перейти в каталог Coreutils */

250 Directory successfully changed.

ftp> bin

200 Switching to Binary mode.

ftp> hash /* Выводить символы # по мере закачки */

Hash mark printing on (1024 bytes/hash mark).

ftp> get coreutils-5.0.tar.gz /* Retrieve file */

local: coreutils-5.0.tar.gz

remote: coreutils-5.0.tar.gz

227 Entering Passive Mode (199,232,41,7,86,107)

150 Opening BINARY mode data connection for coreutils-5.0.tar.gz (6020616 bytes)

######################################################################

######################################################################

...

226 File send OK.

6020616 bytes received in 2.03e+03 secs (2.9 Kbytes/sec)

ftp> quit /* Закончить работу */

221 Goodbye.

Получив файл, извлеките его следующим образом:

$ gzip -dc < coreutils-5.0.tar.gz | tar -xvpf - /* Извлечь файлы */

/* ... при извлечении файла куча вывода ... */

Системы, использующие GNU tar, могут использовать следующее заклинание:

$ tar -xvpzf coreutils-5.0.tar.gz /* Извлечь файлы */

/* ... при извлечении файла куча вывода ... */

В соответствии с общедоступной лицензией GNU, вот сведения об авторских правах для всех GNU программ, процитированных в данной книге. Все программы являются «свободным программным обеспечением; вы можете распространять их и/или модифицировать на условиях общедоступной лицензии GNU в изданном Фондом бесплатных программ виде; либо версии 2 лицензии, либо (по вашему выбору) любой последующей версии». Текст общедоступной лицензии GNU см. в приложении С «Общедоступная лицензия GNU».

Файл Coreutils 5.0 Даты авторского права
lib/safe-read.с © 1993-1994, 1998, 2002
lib/safe-write.c © 2002
lib/utime.c © 1998, 2001-2002
lib/xreadlink.с © 2001
src/du.c © 1988-1991, 1995-2003
src/env.с © 1986, 1991-2003
src/install.с © 1989-1991, 1995-2002
src/link.c © 2001-2002
src/ls.с © 1985, 1988, 1990, 1991, 1995-2003
src/pathchk.c © 1991-2003
src/sort.с © 1988, 1991-2002
src/sys2.h © 1997-2003
src/wc.с © 1985, 1991, 1995-2002
Файл Gawk 3.0.6 Даты авторского права
eval.с © 1986, 1988, 1989, 1991-2000
Файл Gawk 3.1.3 Даты авторского права
awk.h © 1986, 1988, 1989, 1991-2003
builtin.с © 1986, 1988, 1989, 1991-2003
eval.с © 1986, 1988, 1989, 1991-2003
io.c © 1986, 1988, 1989, 1991-2003
main.с © 1986, 1988, 1989, 1991-2003
posix/gawkmisc.с © 1986, 1988, 1989, 1991-1998, 2001-2003
Файл Gawk 3.1.4 Даты авторского права
builtin.c © 1986, 1988, 1989, 1991-2004
Файл GLIBC 23.2 Даты авторского права
locale/locale.h © 1991, 1992, 1995-2002
posix/unistd.h © 1991-2003
time/sys/time.h © 1991-1994, 1996-2003
Файл Make 3.80 Даты авторского права
read.с © 1988-1997, 2002
Где получить примеры программ, использованные в данной книге
Примеры программ, использованные в данной книге, можно найти по адресу: http://authors.phptr.com/robbins.

Об обложке
«Это оружие Джедая …, элегантное оружие для более цивилизованной эпохи. На протяжении тысяч поколений Рыцари Джедай были защитниками мира и справедливости в Старой Республике. От мрачных времен, до Империи».

- Оби-Ван Кеноби -
Возможно, вы удивляетесь, почему мы поместили на обложке легкую саблю и использовали ее во внутреннем оформлении книги. Что она представляет и какое она имеет отношение к программированию под Linux?

В руках Рыцаря Джедай легкая сабля является и мощным оружием, и предметом красоты. Ее использование демонстрирует мощь, знание, контроль над Силой и напряженное обучение для владеющего им Джедая.

Элегантность легкой сабли отражает элегантность оригинального дизайна Unix API. Там также обдуманное, точное использование API и программных инструментов и принципов проектирования GNU привело к сегодняшним мощным, гибким, развитым системам GNU/Linux. Эта система демонстрирует знание и понимание программистов, создавших все их компоненты.

И конечно, легкие сабли — это просто круто!

Благодарности
Написание книги требует большого количества работы, а чтобы сделать это хорошо, нужна помощь от многих людей. Д-р Brian W. Kernighan, д-р Doug McIlroy, Peter Memishian и Peter van der Linden сделали рецензию первоначального предложения. David J. Agans, Fred Fish, Don Marti, Jim Meyering, Peter Norvig и Julian Seward достали разрешения на воспроизведение различных элементов, процитированных по всей книге. Спасибо Geoff Collyer, Ulrich Drepper, Yosef Gold, д-ру C.A.R. (Tony) Hoare, д-ру Manny Lehman, Jim Meyering, д-ру Dennis M. Ritchie, Julian Seward, Henry Spencer и д-ру Wladyslaw M. Turski за предоставление множества полезной общей информации. Спасибо также другим членам группы GNITS. Karl Berry, Akim DeMaille, Ulrich Drepper, Greg McGary, Jim Meyering, Francois Pinard и Tom Tromey, которые предоставили полезную обратную связь относительно хорошей практики программирования. Karl Berry, Alper Ersoy и д-р Nelson H.F. Beebe предоставили ценную техническую помощь по Texinfo и DocBook/XML.

Хорошие технические обзоры не только гарантируют, что автор использует правильные факты, они также гарантируют, что он тщательно обдумывает свое представление. Д-р Nelson H.F. Beebe, Geoff Collyer, Russ Cox, Ulrich Drepper, Randy Lechlitner, д-р Brian W. Kernighan, Peter Memishian, Jim Meyering, Chet Ramey и Louis Taber работали в качестве технических рецензентов для всей книги. Д-р Michael Brennan предоставил полезные комментарии для главы 15. Их рецензии принесли пользу как содержанию, так и многим примерам программ. Настоящим я благодарю их всех. Как обычно говорят в таких случаях большинство авторов, «все оставшиеся ошибки мои».

Я особенно хотел бы поблагодарить Mark Taub из Pearson Education за инициирование этого проекта, за его энтузиазм для этой серии и за его помощь и советы по мере прохождения книги через различные ее стадии. Anthony Gemmellaro сделал феноменальную работу по реализации моей идеи для обложки, а внутренний дизайн Gail Cocker великолепен. Faye Gemmellaro сделал процесс производства вместо рутины приятным. Dmitry Kirsanov и Alina Kirsanova сделали рисунки, макеты страниц и предметный указатель; работать с ними было одно удовольствие.

Наконец, моя глубочайшая благодарность жене Мириам за ее поддержку и ободрение во время написания книги.

Арнольд Роббинс
Nof Ayalon
ИЗРАИЛЬ

Часть 1 Файлы и пользователи

Глава 1 Введение

Если есть одна фраза, резюмирующая важнейшие понятия GNU/Linux (а следовательно, и Unix), это «файлы и процессы». В данной главе мы рассмотрим модели файлов и процессов в Linux. Их важно понять, потому что почти все системные вызовы имеют отношение к изменению какого-либо атрибута или части состояния файла или процесса.

Далее, поскольку мы будем изучать код в обеих стилях, мы кратко рассмотрим главные различия между стандартным С 1990 г. и первоначальным С. Наконец, мы довольно подробно обсудим то, что делает GNU-программы «лучше» — принципы программирования, использование которых в коде мы увидим.

В данной главе содержится ряд умышленных упрощений. Детали в подробностях будут освещены по мере продвижения по книге. Если вы уже являетесь специалистом в Linux, пожалуйста, простите нас

1.1. Модель файловой системы Linux/Unix

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

Поиск простоты направлялся двумя факторами. С технической точки зрения, первоначальные мини-компьютеры PDP-11, на которых разрабатывалась Unix, имели маленькое адресное пространство: 64 килобайта на меньших системах, 64 Кб кода и 64 Кб данных на больших. Эти ограничения относились не только к обычным программам (так называемому коду уровня пользователя), но и к самой операционной системе (коду уровня ядра). Поэтому не только «Маленький — значит красивый» в эстетическом смысле, но «Маленький — значит красивый», потому что не было другого выбора!

Вторым фактором была отрицательная реакция на современные коммерческие операционные системы, которые были без надобности усложнены, со сложными командными языками, множеством разновидностей файлового ввода-вывода и слабой общностью или гармонией. (Стив Джонсон однажды заметил: «Использование TSO подобно пинанию мертвого кита на побережье». TSO — это как раз одна из только что описанных бестолковых систем с разделением времени «для мэйнфреймов.)

1.1.1. Файлы и права доступа

Файловая модель Unix проста, как фраза: файл — это линейный поток байтов. Точка. Операционная система не накладывает на файлы никаких предопределенных структур, ни фиксированных или переменных размеров записей, ни индексированных файлов, ничего. Интерпретация содержимого файла целиком оставлена приложению. (Это не совсем верно, как мы вскоре увидим, но для начала достаточно близко к истине.)

Если у вас есть файл, вы можете сделать с данными в файле три вещи: прочитать, записать или исполнить их.

Unix разрабатывался для мини-компьютеров с разделением времени; это предполагает наличие с самого начала многопользовательского окружения. Раз есть множество пользователей, должно быть возможным указание прав доступа к файлам: возможно, пользователь jane является начальником пользователя fred, и jane не хочет, чтобы fred прочел последние результаты аттестации.

В целях создания прав доступа пользователи подразделяются на три различные категории: владелец файла; группа пользователей, связанная с данным файлом (вскоре будет пояснено); и остальные пользователи. Для каждой из этих категорий каждый файл имеет отдельные, связанные с этим файлом, биты прав доступа, разрешающие чтение, запись и исполнение. Эти разрешения отображаются в первом поле вывода команды 'ls -l':

$ ls -l progex.texi

-rw-r--r-- 1 arnold devel 5614 Feb 24 18:02 progex.texi

Здесь arnold и devel являются соответственно владельцем и группой файла progex.texi, a -rw-r--r-- является строкой типа файла и прав доступа. Для обычного файла первым символом будет дефис, для каталогов - d, а для других видов файлов - небольшой набор других символов, которые пока не имеют значения. Каждая последующая тройка символов представляют права на чтение, запись и исполнение для владельца, группы и «остальных» соответственно.

В данном примере файл progex.texi может читать и записывать владелец файла, а группа и остальные пользователи могут только читать. Дефисы означают отсутствие разрешений, поэтому этот файл никто не может исполнить, а группа и остальные пользователи не могут в него записывать.

Владелец и группа файла хранятся в виде числовых значений, известных как идентификатор пользователя (user ID — UID) и идентификатор группы (group ID — GID); стандартные библиотечные функции, которые мы рассмотрим далее в книге, позволяют напечатать эти значения в виде читаемых имен.

Владелец файла может изменить разрешения, используя команду chmod (change mode — изменить режим). (Права доступа к файлу, по существу, иногда называют «режимом файла».) Группу файла можно изменить с помощью команд chgrp (change group — изменить группу) и chown (change owner — сменить владельца)[11].

Групповые права доступа были нацелены на поддержку совместной работы: хотя определенным файлом может владеть один член группы или подразделения, возможно, каждый член группы должен иметь возможность изменять его. (Рассмотрите совместный маркетинговый доклад или данные исследования.)

Когда система проверяет доступ к файлу (обычно при открытии файла), если UID процесса совпадает с UID файла, используются права доступа владельца файла. Если эти права доступа запрещают операцию (скажем, попытка записи в файл с доступом -r--rw-rw-), операция завершается неудачей; Unix и Linux не продолжают проверку прав доступа для группы и других пользователей[12]. Это верно также, если UID различаются, но совпадают GID; если права доступа группы запрещают операцию, она завершается неудачей.

Unix и Linux поддерживают понятие суперпользователя (superuser): это пользователь с особыми привилегиями. Этот пользователь известен как root и имеет UID, равный 0. root позволено делать все; никаких проверок, все двери открыты, все ящики отперты.[13] (Это может иметь важные последствия для безопасности, которых мы будем касаться по всей книге, но не будем освещать исчерпывающе.) Поэтому, даже если файл имеет режим ----------, root все равно может читать файл и записывать в него. (Исключением является то, что файл нельзя исполнить. Но поскольку root может добавить право на исполнение, это ограничение ничего не предотвращает.)

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

1.1.2. Каталоги и имена файлов

Раз у вас есть файл, нужно где-то его хранить. В этом назначение каталога (известного в системах Windows или Apple Macintosh под названием «папка»). Каталог является особой разновидностью файла, связывающего имена файлов с метаданными, известными как узлы (inodes). Каталоги являются особыми, поскольку их может обновлять лишь операционная система путем описанных в главе 4, «Файлы и файловый ввод-вывод», системных вызовов. Они особые также потому, что операционная система предписывает формат элементов каталога.

Имена файлов могут содержать любой 8-битный байт, за исключением символа '/' (прямой косой черты) и ASCII символа NUL, все биты которого содержат 0. Ранние Unix- системы ограничивали имена 14 байтами; современные системы допускают отдельные имена файлов вплоть до 255 байтов.

Узел содержит всю информацию о файле, за исключением его имени: тип, владелец, группа, права допуска, размер, времена изменения и доступа. Он хранит также размещение на диске блоков, содержащих данные файла. Все это данные о файле, а не данные самого файла, отсюда термин метаданные.

Права доступа к каталогам по сравнению с правами доступа к файлам имеют несколько другой смысл. Разрешение на чтение означает возможность поиска в каталоге, т.е. его просмотр с целью определить, какие файлы в нем содержатся. Разрешение на запись дает возможность создавать и удалять файлы в каталоге. Разрешение на исполнение означает возможность прохода через каталог при открытии или ином доступе к содержащемуся файлу или подкаталогу.

ЗАМЕЧАНИЕ. Если у вас есть разрешение на запись в каталог, вы можете удалять файлы из этого каталога, даже если они не принадлежат вам! При интерактивной работе команда rm отмечает это, запрашивая в таком случае подтверждение

Каталог /tmp имеет разрешение на запись для каждого, но ваши файлы в /tmp находятся вполне в безопасности, поскольку /tmp обычно имеет установленный так называемый «липкий» (sticky) бит:

$ ls -ld /trap

drwxrwxrwt 11 root root 4096 May 15 17:11 /tmp

Обратите внимание, что t находится в последней позиции первого поля. В большинстве каталогов в этом месте стоит x. При установленном «липком» бите ваши файлы можете удалять лишь вы, как владелец файла, илиroot. (Более детально это обсуждается в разделе 11.2 5, «Каталоги и липкий бит».)

1.1.3. Исполняемые файлы

Помните, мы говорили, что операционная система на накладывает структуру на файлы? Мы уже видели, что это было невинной ложью относительно каталогов. Это же относится к двоичным исполняемым файлам. Чтобы запустить программу, ядро должно знать, какая часть файла представляет инструкции (код), а какая — данные. Это ведет к понятию формата объектного файла, которое определяет, как эти данные располагаются внутри файла на диске.

Хотя ядро запустит лишь файлы, имеющие соответствующий формат, создание таких файлов задача утилит режима пользователя. Компилятор с языка программирования (такого как Ada, Fortran, С или С++) создает объектные файлы, а затем компоновщик или загрузчик (обычно с именем ld) связывает объектные файлы с библиотечными функциями для окончательного создания исполняемого файла. Обратите внимание, что даже если все нужные биты в файле размешены в нужных местах, ядро не запустит его, если не установлен соответствующий бит, разрешающий исполнение (или хотя бы один исполняющий бит для root).

Поскольку компилятор, ассемблер и загрузчик являются инструментами режима пользователя, изменить со временем по мере необходимости форматы объектных файлов (сравнительно) просто; надо только «научить» ядро новому формату, и он может быть использован. Часть ядра, загружающая исполняемые файлы, относительно невелика, и это не является невозможной задачей. Поэтому форматы файлов Unix развиваются с течением времени. Первоначальный формат был известен как a.out (Assembler OUTput — вывод сборщика). Следующий формат, до сих пор использующийся в некоторых коммерческих системах, известен как COFF (Common Object File Format — общий формат объектных файлов), а современный, наиболее широко использующийся формат — ELF (Extensible Linking Format — открытый формат компоновки). Современные системы GNU/Linux используют ELF.

Ядро распознает, что исполняемый файл содержит двоичный объектный код, проверяя первые несколько байтов файла на предмет совпадения со специальными магическими числами. Это последовательности двух или четырех байтов, которые ядро распознает в качестве специальных. Для обратной совместимости современные Unix-системы распознают несколько форматов. Файлы ELF начинаются с четырех символов «\177ELF».

Помимо двоичных исполняемых файлов, ядро поддерживает также исполняемые сценарии (скрипты). Такой файл также начинается с магического числа: в этом случае, это два обычных символа # ! . Сценарий является программой, исполняемой интерпретатором, таким, как командный процессор, awk, Perl, Python или Tcl. Строка, начинающаяся с #!, предоставляет полный путь к интерпретатору и один необязательный аргумент:

#! /bin/awk -f

BEGIN {print "hello, world"}

Предположим, указанное содержимое располагается в файле hello.awk и этот файл исполняемый. Когда вы набираете 'hello.awk', ядро запускает программу, как если бы вы напечатали '/bin/awk -f hello.awk'. Любые дополнительные аргументы командной строки также передаются программе. В этом случае, awk запускает программу и отображает общеизвестное сообщение hello, world.

Механизм с использованием #! является элегантным способом скрыть различие между двоичными исполняемыми файлами и сценариями. Если hello.awk переименовать просто в hello, пользователь, набирающий 'hello', не сможет сказать (и, конечно, не должен знать), что hello не является двоичной исполняемой программой.

1.1.4. Устройства

Одним из самых замечательных новшеств Unix было объединение файлового ввода- вывода и ввода-вывода от устройств.[14] Устройства выглядят в файловой системе как файлы, для доступа к ним используются обычные права доступа, а для их открытия, чтения, записи и закрытия используются те же самые системные вызовы ввода-вывода. Вся «магия», заставляющая устройства выглядеть подобно файлам, скрыта в ядре. Это просто другой аспект движущего принципа простоты в действии, мы можем выразить это как никаких частных случаев для кода пользователя.

В повседневной практике, в частности, на уровне оболочки, часто появляются два устройства: /dev/null и /dev/tty.

/dev/null является «битоприемником». Все данные, посылаемые /dev/null, уничтожаются операционной системой, а все попытки прочесть отсюда немедленно возвращают конец файла (EOF).

/dev/tty является текущим управляющим терминалом процесса — тем, который он слушает, когда пользователь набирает символ прерывания (обычно CTRL-C) или выполняет управление заданием (CTRL-Z).

Системы GNU/Linux и многие современные системы Unix предоставляют устройства /dev/stdin, /dev/stdout и /dev/stderr, которые дают возможность указать открытые файлы, которые каждый процесс наследует при своем запуске.

Другие устройства представляют реальное оборудование, такое, как ленточные и дисковые приводы, приводы CD-ROM и последовательные порты. Имеются также программные устройства, такие, как псевдотерминалы, которые используются для сетевых входов в систему и систем управления окнами, /dev/console представляет системную консоль, особое аппаратное устройство мини-компьютеров. В современных компьютерах /dev/console представлен экраном и клавиатурой, но это может быть также и последовательный порт

К сожалению, соглашения по именованию устройств не стандартизированы, и каждая операционная система использует для лент, дисков и т.п. собственные имена. (К счастью, это не представляет проблемы для того, что мы рассматриваем в данной книге.) Устройства имеют в выводе 'ls -l' в качестве первого символа b или с.

$ ls -l /dev/tty /dev/hda

brw-rw-rw- 1 root disk 3, 0 Aug 31 02:31 /dev/hda

crw-rw-rw- 1 root root 5, 0 Feb 26 08:44 /dev/tty

Начальная 'b' представляет блочные устройства, а 'c' представляет символьные устройства. Файлы устройств обсуждаются далее в разделе 5.4, «Получение информации о файлах».

1.2. Модель процессов Linux/Unix

Процесс является работающей программой.[15] Процесс имеет следующие атрибуты:

уникальный идентификатор процесса (PID);

• родительский процесс (с соответствующим идентификатором, PPID);

• идентификаторы прав доступа (UID, GID, набор групп и т.д.);

• отдельное от всех других процессов адресное пространство;

• программа, работающая в этом адресном пространстве;

• текущий рабочий каталог ('.');

• текущий корневой каталог (/; его изменение является продвинутой темой);

• набор открытых файлов, каталогов, или и того, и другого;

• маска запретов доступа, использующаяся при создании новых файлов;

• набор строк, представляющих окружение[16];

• приоритеты распределения времени процессора (продвинутая тема);

• установки для размещения сигналов (signal disposition) (продвинутая тема); управляющий терминал (тоже продвинутая тема).

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

Новые процессы всегда создаются существующими процессами. Существующий процесс называется родительским, а новый процесс — порожденным. При загрузке ядро вручную создает первый, изначальный процесс, который запускает программу /sbin/init; идентификатор этого процесса равен 1, он осуществляет несколько административных функций. Все остальные процессы являются потомками init. (Родительским процессом init является ядро, часто обозначаемое в списках как процесс с ID 0.)

Отношение порожденный-родительский является отношением один к одному; у каждого процесса есть только один родитель, поэтому легко выяснить PID родителя. Отношение родительский-порожденный является отношением один ко многим; каждый данный процесс может создать потенциально неограниченное число порожденных. Поэтому для процесса нет простого способа выяснить все PID своих потомков. (Во всяком случае, на практике это не требуется.) Родительский процесс можно настроить так, чтобы он получал уведомление при завершении порожденного процесса, он может также явным образом ожидать наступления такого события.

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

Текущий рабочий каталог — это каталог, относительно которого отсчитываются относительные пути файлов (те, которые не начинаются с '/'). Это каталог, в котором вы находитесь, когда набираете команду оболочки 'cd someplace'.

По соглашению, все программы запускаются с тремя уже открытыми файлами: стандартным вводом, стандартным выводом и стандартной ошибкой. Это места, откуда принимается ввод, куда направляется вывод и куда направляются сообщения об ошибках соответственно. На протяжении этой книги мы увидим, как они назначаются. Родительский процесс может открыть дополнительные файлы и сделать их доступными для порожденных процессов; порожденный процесс должен каким-то образом узнать, что они есть, либо посредством какого-либо соглашения, либо через аргументы командной строки или переменную окружения.

Окружение представляет собой набор строк, каждая в виде 'имя=значение'. Для запроса и установки значений переменных окружения имеются специальные функции, а порожденные процессы наследуют окружение своих родителей. Типичными переменными окружения оболочки являются PATH и НОМЕ. Многие программы для управления своим поведением полагаются на наличие и значения определенных переменных окружения.

Важно понять, что один процесс в течение своего существования может исполнить множество программ. Все устанавливаемые системой атрибуты (текущий каталог, открытые файлы, PID и т.д.) остаются теми же самыми, если только они не изменены явным образом. Отделение «запуска нового процесса» от «выбора программы для запуска» является ключевым нововведением Unix. Это упрощает многие операции. Другие операционные системы, которые объединяют эти две операции, являются менее общими и их сложнее использовать.

1.2.1. Каналы: сцепление процессов

Без сомнения, вам приходилось использовать конструкцию ('|') оболочки для соединения двух или более запущенных программ. Канал действует подобно файлу: один процесс записывает в него, используя обычную операцию записи, а другой процесс считывает из него с помощью операции чтения. Процессы (обычно) не знают, что их ввод/вывод является каналом, а не обычным файлом.

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

Таким образом, принцип файлового ввода/вывода применительно к каналам служит ключевым механизмом для связывания запушенных программ; не требуется никаких временных файлов. Опять-таки общность и простота работы: никаких особых случаев для кода пользователя.

1.3. Стандартный С против оригинального С

В течение многих лет определение С де-факто можно было найти в первом издании книги Брайана Кернигана и Денниса Ричи «Язык программирования С» (Brian Kernighan & Dennis Ritchie, The С Programming Language). Эта книга описала С, как он существовал для Unix и на системах, на которые его перенесли разработчики лаборатории Bell Labs. На протяжении данной книги мы называем его как «оригинальный С», хотя обычным является также название «С Кернигана и Ричи» («K&R С»), по именам двух авторов книги. (Деннис Ричи разработал и реализовал С.)

Стандарт ISO С 1990 г.[17] формализовал определения языка, включая функции библиотеки С (такие, как printf() и fopen()). Комитет по стандартам С проделал замечательную работу по стандартизации существующей практики и избежал введения новых возможностей, с одним значительным исключением (и несколькими незначительными). Наиболее заметным изменением языка было использование прототипов функций, заимствованных от С++.

Стандартные языки программирования С, C++ и Java используют прототипы функций для объявлений и определений функций. Прототип описывает не только возвращаемое значение функции, но также и число и тип ее аргументов. С прототипами компилятор может выполнить проверку типов в точке вызова функции:

Объявление

extern int myfunc(struct my_struct *a,

 struct my_struct *b, double c, int d);

Определение

int myfunc(struct my_struct *a,

 struct my_struct *b, double c, int d) {

 ...

}

...

struct my_struct s, t;

int j;

...

/* Вызов функции, где-то в другом месте: */

j = my_func(&s, &t, 3.1415, 42);

Это правильный вызов функции. Но рассмотрите ошибочный вызов:

j = my_func(-1, -2, 0);

/* Ошибочные число и типы аргументов */

Компилятор может сразу же определить этот вызов как неверный. Однако, в оригинальном С функции объявляются без указания списка аргументов:

extern int myfunc();

/* Возвращает int, аргументы неизвестны */

Более того, определения функций перечисляют имена параметров в заголовке функции, затем объявляют параметры перед телом функции. Параметры типа int объявлять не нужно, и если функция возвращает int, его тоже не нужно объявлять:

myfunc(a, b, с, d); /* Возвращаемый тип int*/

struct my_struct *а, *b;

double с;

/* Обратите внимание, нет объявления параметра d*/

{

 ...

}

Рассмотрите снова тот же ошибочный вызов функции: 'j = my_func(-1, -2 , 0);'. В оригинальном С у компилятора нет возможности узнать, что вы (ошибочно, полагаем) передали my_func() ошибочные аргументы. Подобные ошибочные вызовы обычно приводят к трудно устранимым проблемам времени исполнения (таким, как ошибки сегментации, из-за чего программа завершается), и для работы с такими вещами была создана программа Unix lint.

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

Для С стандарта 1990 г. код, написанный в оригинальном стиле, является действительным как для объявлений, так и для определений. Это дает возможность продолжать компилировать миллионы строк существующего кода с помощью компилятора, удовлетворяющего стандарту. Новый код, очевидно, должен быть написан с прототипами из-за улучшенных возможностей проверки ошибок времени компилирования.

Стандарт С 1999 г.[18] продолжает допускать объявления и определения в оригинальном стиле. Однако, правило «неявного int» было убрано; функции должны иметь возвращаемый тип, а все параметры должны быть объявлены.

Более того, когда программа вызывала функцию, которая не была формально объявлена, оригинальный С создал бы для функции неявное объявление с возвращаемым типом int. С стандарта 1999 г. делал то же самое, дополнительно отметив, что у него не было информации о параметрах. С стандарта 1999 г. не предоставляет больше возможности «автоматического объявления».

Другими заметными дополнениями в стандарте С являются ключевое слово const, также из С++, и ключевое слово volatile, которое придумал комитет. Для кода, который вы увидите в этой книге, наиболее важной вещью является понимание различных синтаксисов объявлений и определений функций.

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

Хотя стандарт С 1999 г. добавляет некоторые дополнительные ключевые слова и возможности, отсутствующие в версии 1990 г., мы решили придерживаться диалекта 1990 г, поскольку компиляторы C99 не являются пока типичными. Практически, это не имеет значения: код C89 должен компилироваться и запускаться без изменений при использовании компилятора C99, а новые возможности C99 не затрагивают наше обсуждение или использование фундаментальных API Linux/Unix.

1.4. Почему программы GNU лучше

Что делает программу GNU программой GNU?[19] Что делает программное обеспечение GNU «лучше» по сравнению с другим (платным или бесплатным) программным обеспечением? Наиболее очевидной разницей является общедоступная лицензия (General Public License — GPL), которая описывает условия распространения для программного обеспечения GNU. Но это обычно не причина, чтобы вы могли услышать, как люди говорят: «Дайте GNU-версию xyz, она намного лучше». Программное обеспечение GNU в общем более устойчиво, имеет лучшую производительность, чем в стандартных версиях Unix. В данном разделе мы рассмотрим некоторые причины этого явления, а также рассмотрим документ, описывающий принципы проектирования программного обеспечения GNU.

«Стандарты кодирования GNU» (GNU Coding Standards) описывают создание программного обеспечения для проекта GNU. Они охватывает ряд тем. Вы можете найти GNU Coding Standards по адресу http://www.gnu.org/prep/standards.html. Смотрите в онлайн-версии ссылки на исходные файлы в других форматах.

В данном разделе мы описываем лишь те части GNU Coding Standards, которые относятся к проектированию и реализации программ.

1.4.1. Проектирование программ

Глава 3 GNU Coding Standards содержит общие советы относительно проектирования программ. Четырьмя главными проблемами являются совместимость (со стандартами и с Unix), язык, использование нестандартных возможностей других программ (одним словом, «ничего»), и смысл «переносимости».

Важной целью является совместимость со стандартом С и POSIX, а также, в меньшей степени, с Berkley Unix. Но она не преобладает. Общей идеей является предоставление всех необходимых возможностей через аргументы командной строки для предоставления точного режима ISO или POSIX.

Предпочтительным языком для написания программного обеспечения GNU является С, поскольку это наиболее доступный язык. В мире Unix стандарт С теперь обычен, но если для вас не представляет труда поддержка оригинального С, вы должны сделать это. Хотя стандарты кодирования отдают предпочтение С перед С++, C++ теперь тоже вполне обычен. Примером широко используемого пакета GNU, написанного на С++, является groff (GNU troff). Наш опыт говорит, что с GCC, поддерживающим С++, установка groff не представляет сложности.

Стандарты утверждают, что переносимость является чем-то вроде отвлекающего маневра. Утилиты GNU ясно нацелены на работу с ядром GNU и с библиотекой GNU С[20]. Но поскольку ядро еще не завершено, и пользователи используют инструменты GNU на не-GNU системах, переносимость желательна, но не является первостепенной задачей. Стандарт рекомендует для достижения переносимости между различными системами Unix использовать Autoconf.

1.4.2. Поведение программы

Глава 4 GNU Coding Standards предоставляет общие советы относительно поведения программы. Ниже мы вернемся к одному из ее разделов для более подробного рассмотрения. Глава фокусируется на строении программы, форматировании сообщений об ошибках, написании библиотек (делая их рентабельными) и стандартах для интерфейса командной строки.

Форматирование сообщений об ошибках важно, поскольку несколько инструментов, особенно Emacs, используют сообщения об ошибках, чтобы помочь вам попасть в то место в исходном файле или файле данных, где произошла ошибка.

Утилиты GNU должны использовать для обработки командной строки функцию getopt_long(). Эта функция предусматривает разбор аргументов командной строки как для опций в стиле традиционного Unix ('gawk -F:...'), так и для длинных опций в стиле GNU ('gawk --field-separator=:...'). Все программы должны предусматривать опции --help и --version, а когда в одной программе используется длинное имя, оно таким же образом должно использоваться и в другой программе GNU. Для этой цели есть довольно полный список длинных опций, используемых современными GNU-программами.

В качестве простого, но очевидного примера, --verbose пишется точно таким же способом во всех GNU-программах. Сравните это с -v, -V, -d и т.д. во многих других программах Unix. Большая часть главы 2, «Аргументы, опции и окружение», с. 23, посвящена механике разбора аргументов и опций.

1.4.3. Программирование на С

Наиболее привлекательной частью GNU Coding Standards является глава 5, которая описывает написание кода на С, освещая такие темы, как форматирование кода, правильное использование комментариев, чистое использование С, именование ваших функций и переменных, а также объявление или не объявление стандартных системных функций, которые вы хотите использовать.

Форматирование кода является религиозной проблемой; у многих людей разные стили, которые они предпочитают. Лично нам не нравится стиль FSF, и если вы взглянете на gawk, который мы поддерживаем, вы увидите, что он форматирован в стандартном стиле K&R (стиль расположения кода, использованный в обоих изданиях книги Кернигана и Ричи). Но это единственное отклонение в gawk от этой части стандартов кодирования.

Тем не менее, хотя нам и не нравится стиль FSF[21], мы чувствуем, что при модификации некоторых других программ, придерживание уже использованного стиля кода является исключительно важным. Последовательность в стиле кода более важна, чем сам стиль, который вы выбираете. GNU Coding Standards дает такой же совет. (Иногда невозможно обнаружить последовательный стиль кода, в этом случае программа, возможно, испорчена использованием indent от GNU или cb от Unix.)

Что мы сочли важным в главе о написании кода на С, это то, что эти советы хороши для любого кода на С, а не только когда вы работаете над программой GNU. Поэтому, если вы просто учите С или даже если вы уже работали некоторое время на С (или С++), мы рекомендуем вам эту главу, поскольку она заключает в себе многолетний опыт.

1.4.4. Вещи, которые делают программы GNU лучше

Теперь мы рассмотрим раздел, озаглавленный «Написание надежных программ», в главе 4 «Поведение программ для всех программ». Этот раздел описывает принципы проектирования программного обеспечения, которые делают программы GNU лучше их двойников в Unix Мы процитируем выбранные части главы, с несколькими примерами случаев, в которых эти принципы окупились.

Избегайте произвольных ограничений длины или числа любой структуры данных, включая имена файлов, строки, файлы и символы, выделяя все структуры данных динамически. В большинстве инструментов Unix «длинные строки молча срезаются». Это неприемлемо в инструменте GNU.

Это правило, возможно, единственное наиболее важное в проектировании программного обеспечения GNU — никаких произвольных ограничений. Все инструменты GNU должны быть способны обрабатывать произвольные объемы данных.

Хотя это требование, возможно, усложняет работу программиста, оно облегчает жизнь пользователю. С одной стороны, у нас есть пользователь gawk, регулярно запускающий программу awk для более чем 650 000 файлов (нет, это не опечатка) для сбора статистики, gawk заняла бы более 192 мегабайтов пространства данных, и программа работала бы в течение 7 часов. Он не смог бы запустить эту программу, используя другую реализацию awk.[22]

Утилиты, читающие файлы, не должны удалять символы NUL или любые другие неотображаемые символы, включая символы с кодами больше 0177. Единственными здравыми исключениями были бы утилиты, специально предназначенные для связывания с определенными типами терминалов или принтеров, которые не могут обработать эти символы.

Также хорошо известно, что Emacs может редактировать любые произвольные файлы, включая файлы, содержащие двоичные данные!

По возможности, программы должны обрабатывать должным образом последовательности байтов, представляющих многобайтные символы, используя такие кодировки, как UTF-8 и другие.[23] Каждый системный вызов проверяйте на предмет возвращенной ошибки, если вы не хотите игнорировать ошибки. Включите текст системной ошибки (от perror или эквивалентной функции) в каждое сообщение об ошибке, возникшей при неудачном системном вызове, также, как и имя файла, если он есть, и имя утилиты. Простого «невозможно открыть foo.с» или «ошибка запуска» недостаточно.

Проверка каждого системного вызова создает устойчивость. Это еще один случай, когда жизнь программиста труднее, а пользователя легче. Подробно описанное сообщение об ошибке значительно упрощает нахождение и разрешение проблем[24].

Наконец, мы цитируем главу 1 GNU Coding Standards, которая обсуждает, как написать вашу программу способом, отличным от того, каким написаны программы Unix.

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

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

Или выделите части программы в независимо используемые библиотеки. Или используйте простой сборщик мусора вместо точного отслеживания, когда освобождать память, или используйте новую возможность GNU, такую как obstacks.

Великолепным примером того, какое отличие можно сделать в алгоритме, является GNU diff. Одним из первых ранних воплощений нашей системы было AT&T 3B1, система с процессором МС68010, огромными двумя мегабайтами памяти и 80 мегабайтами на диске. Мы проделали (и делаем) кучу исправлений в руководстве для gawk, файле длиной почти 28 000 строк (хотя в то время он был лишь в диапазоне 10 000 строк). Обычно мы частенько использовали 'diff -с', чтобы посмотреть на сделанные нами изменения. На этой медленной системе переключение на GNU diff показало ошеломительную разницу во времени появления контекста diff. Разница почти всецело благодаря лучшему алгоритму, который использует GNU diff.

В последнем параграфе упоминается идея структурирования программы как независимо используемой библиотеки, с оболочкой командной строки или другим окружающим се интерфейсом. Примером этого является GDB, отладчик GNU, который реализован в виде инструмента с интерфейсом командной строки поверх отладочной библиотеки. (Разделение основных возможностей GDB от интерфейса командной строки является продолжающимся проектом). Эта реализация дает возможность создать поверх отладочных функциональных возможностей графический интерфейс отладчика.

1.4.5. Заключительные соображения по поводу «GNU Coding Standards»

GNU Coding Standards является стоящим для прочтения документом, если вы хотите разрабатывать новое программное обеспечение GNU, обмениваться существующими программами GNU или просто научиться программировать лучше. Принципы и методики, которые она поддерживает — вот что делает программное обеспечение GNU предпочитаемым выбором в сообществе Unix.

1.5. Пересмотренная переносимость

Переносимость является чем-то вроде Святого Грааля; всегда недостающим впоследствии, но не всегда достижимым и определенно нелегким. Есть несколько аспектов написания переносимого кода. GNU Coding Standards обсуждает многие из них. Но есть и другие стороны. При разработке принимайте переносимость во внимание как на высоком, так и на низком уровнях. Мы рекомендуем следующие правила:

Соответствуйте стандартам

Хотя это может потребовать напряжения, знакомство с формальными стандартами языка, который вы используете, окупается. В частности, обратите внимание на стандарты ISO 1990 и 1999 гг. для С и стандарт 2003 г. для С++, поскольку большинство программ Linux создано на одном из этих двух языков.

В промышленности также широко поддерживается стандарт POSIX для интерфейса библиотечных и системных вызовов, хотя он и большой. Написание в соответствии с POSIX значительно повышает шансы успешного переноса вашего кода и на другие системы, помимо GNU/Linux. Этот стандарт вполне читабелен; он концентрирует в себе десятилетия опыта и хорошей практики.

Выбирайте для работы лучший интерфейс

Если стандартный интерфейс выполняет нужную вам работу, используйте его в своем коде. Для обнаружения недоступного интерфейса используйте Autoconf, и добавьте его замещающую версию для ограниченной системы. (Например, на некоторых более старых системах отсутствует функция memmove(), которую довольно легко запрограммировать самому или вставить из библиотеки GLIBC).

Изолируйте проблемы переносимости за новыми интерфейсами

Иногда вам может потребоваться выполнить специфичные для операционной системы задачи, которые можно исполнить на одних системах, но нельзя на других. (Например, на некоторых системах каждая программа должна сама раскрывать групповые символы в командной строке, вместо выполнения этой работы командным процессором.) Создайте новый интерфейс, который ничего не делает в системах, которым он не нужен, но проделывает необходимую коррекцию для систем, которые в этом нуждаются.

Используйте для конфигурирования Autoconf

По возможности избегайте #ifdef. Если это невозможно, скройте его в низкоуровневом библиотечном коде. Для проверки тестов, которые должны исполняться с помощью #ifdef, используйте Autoconf.

1.6. Рекомендуемая литература

1. The С Programming Language, 2nd edition, by Brian W. Kernighan and Dennis M. Ritchie Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1989. ISBN: 0-13-110370-9[25].

Это «библия» С, охватывающая версию стандарта С 1990 г. Это довольно сжатая книга, с большим количеством информации, помещенной в поразительно небольшое число страниц. Вам может потребоваться прочитать ее более одного раза; это стоит затраченных усилий.

2. С, A Reference Manual. 5th edition, by Samuel P. Harbison III and Guy L. Steele, Ji. Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.

Это тоже классическая книга. Она охватывает оригинальный С, а также стандарты 1990 и 1999 гг. Поскольку она современна, она служит ценным дополнением к первой книге. Она охватывает многие важные темы, такие, как интернациональные типы и библиотечные функции, которых нет в книге Кернигана и Ричи.

3. Notes on Programming in С, by Rob Pike, February 21,1989 Доступна через множество веб-сайтов. Возможно, чаще всего упоминаемым местом является http://www.lysator.liu.se/c/pikestyle.html. (Многие другие полезные статьи доступны там же на один уровень выше: http://www.lysator.liu.se/с/.) Роб Пайк много лет работал в исследовательском центре Bell Labs, где были созданы С и Unix, и проводил там изыскания. Его замечания концентрируют многолетний опыт в «философию ясности в программировании», это стоит прочтения.

4. Различные ссылки на http://www.chris-lott.org/resources/cstyle/. Этот сайт включает заметки Роба Пайка и несколько статей Генри Спенсера (Henry Spencer). Особенно высокое положение занимает «Рекомендуемый стиль С и стандарты программирования» (Recommended С Style and Coding Standards), первоначально написанный на сайте Bell Labs Indian Hill.

1.7. Резюме

• «Файлы и процессы» суммируют мировоззрение Linux/Unix. Трактовка файлов как потоков байтов, а устройств как файлов, и использование стандартных ввода, вывода и ошибки упрощают построение программ и унифицируют модель доступа к данным. Модель прав доступа проста, но гибка, и приложима как к файлам, так и каталогам.

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

• Наиболее заметным различием между стандартным С и оригинальным С является использование прототипов функций для более строгой проверки типов. Хороший программист на С должен быть способен прочесть код, написанный в оригинальном стиле, поскольку его используют многие существующие программы. Новый код должен быть написан с использованием прототипов.

• GNU Coding Standards описывает написание программ GNU. Она предусматривает многочисленные ценные методики и руководящие принципы для создания надежного, практичного программного обеспечения. Принцип «никаких произвольных ограничений» является, возможно, единственным наиболее важным из них. Этот документ является обязательным для прочтения серьезными программистами.

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

Упражнения

1. Прочтите и прокомментируйте статью Ричарда М. Столмена «Проект GNU» (Richard M. Stallman, «The GNU Project»)[26], первоначально написанную в августе 1998 г.

Глава 2 Аргументы, опции и переменные окружения

Первой задачей любой программы обычно является интерпретация опций и аргументов командной строки. Данная глава рассматривает, как программы С (и С++) получают аргументы своей командной строки, описывает стандартные процедуры для разбора опций и бросает взгляд на переменные окружения.

2.1. Соглашения по опциям и аргументам

У слова аргументы есть два значения. Более техническим определением является «все 'слова' в командной строке». Например:

$ ls main.с opts.с process.с

Здесь пользователь напечатал четыре «слова». Все четыре слова сделаны доступными программе в качестве ее аргументов[27].

Второе определение более неформальное: аргументами являются все слова командной строки, за исключением имени команды. По умолчанию, оболочки Unix отделяют аргументы друг от друга разделителями (пробелами или символами TAB). Кавычки позволяют включать в аргументы разделитель:

$ echo here are lots of spaces

here are lots of spaces /* Оболочка «съедает» пробелы */

$ echo "here are lots of spaces"

here are lots of spaces /* Пробелы остались */

Кавычки прозрачны для запущенной программы; echo никогда не видит символов двойной кавычки. (В оболочке двойные и одинарные кавычки различаются; обсуждение этих правил выходит за рамки данной книги, которая фокусируется на программировании на С.)

Аргументы можно подразделить далее на опции и операнды. В предыдущих двух примерах все аргументы были операндами: файлы для ls и простой текст для echo.

Опции являются специальными аргументами, которые каждая программа интерпретирует. Опции изменяют поведение программы или предоставляют программе информацию. По старому соглашению, которого (почти) всегда придерживаются, опции начинаются с черточки (т.е. дефиса, значка минус), и состоят из единственной буквы. Аргументы опции являются информацией, необходимой для опции, в отличие от обычных аргументов-операндов. Например, опция -f программы fgrep означает «использовать содержимое следующего файла в качестве списка строк для поиска». См. рис 2.1.

Рис. 2.1. Компоненты командной строки

Таким образом, patfile является не файлом данных для поиска, а предназначен для использования fgrep в определении списка строк, которые нужно искать.

2.1.1. Соглашения POSIX

Стандарт POSIX описывает ряд соглашений, которых придерживаются удовлетворяющие стандарту программы. Никто от вас не требует, чтобы ваши программы удовлетворяли этим стандартам, но это хорошая мысль сделать так: пользователи Linux и Unix по всему миру понимают и используют эти соглашения, и если вы не будете им следовать, ваши пользователи будут несчастны. (Или у вас вообще не будет пользователей!) Более того, функции, которые мы обсуждаем далее в этой главе, освобождают вас от бремени ручной реализации этих соглашений для каждой программы, которую вы пишете. Вот эти правила, перефразированные из стандарта:

1. В имени программы должно быть не менее двух и не более девяти символов.

2. Имена программ должны содержать лишь строчные символы и цифры.

3. Имя опции должно быть простым буквенно-цифровым символом. Опции с множеством цифр не должны допускаться. Для производителей, реализующих утилиты POSIX, опция -W зарезервирована для специфичных для производителя опций.

4. Все опции должны начинаться с символа '-'.

5. Для опций, не требующих аргументов, должно быть возможно объединение нескольких опций после единственного символа '-'. (Например, 'foo -a -b -c' и 'foo -abc' должны интерпретироваться одинаково.)

6. Когда опции все же требуется аргумент, он должен быть отделен от опции пробелом (например, 'fgrep -f patfile').

Однако, стандарт допускает историческую практику, при которой иногда опция и ее операнд могут находиться в одной строке: 'fgrep -fpatfile'. На практике функции getopt() и getopt_long() интерпретируют '-fpatfile' как '-f patfile', а не как '-f -p -a -t ...'.

7. Аргументы опций не должны быть необязательными.

Это означает, что если в документации программы указано, что опции требуется аргумент, этот аргумент должен присутствовать всегда, иначе программа потерпит неудачу GNU getopt() все же предусматривает необязательные аргументы опций, поскольку иногда они полезны

8. Если опция принимает аргумент, который может иметь несколько значений, программа должна получать этот аргумент в виде одной строки со значениями, разделенными запятыми или разделителем.

Например, предположим, что гипотетической программе myprog требуется список пользователей для опции -u. Далее она может быть вызвана одним из двух способов:

myprog -u "arnold,joe,jane" /* Разделение запятыми */

myprog -u "arnold joe jane" /* Разделение пробелами */

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

9. Опции должны находиться в командной строке первыми, перед операндами. Версии getopt() Unix проводят в жизнь это соглашение. GNU getopt() по умолчанию этого не делает, хотя вы можете настроить его на это.

10. Специальный аргумент '--' указывает на окончание всех опций. Все последующие аргументы командной строки рассматриваются как операнды, даже если они начинаются с черточки.

11. Порядок, в котором приведены опции, не должен играть роли. Однако, для взаимно исключающих опций, когда одна опция перекрывает установки другой, тогда (так сказать) последняя побеждает. Если опция, имеющая аргумент, повторяется, программа должна обработать аргументы по порядку. Например, 'myprog -u arnold -u jane' то же самое, что и 'myprog -u "arnold, jane"'. (Вам придется осуществить это самостоятельно; getopt() вам не поможет.)

12. Нормально, когда порядок аргументов имеет для программы значение. Каждая программа должна документировать такие вещи.

13. Программы, читающие или записывающие именованные файлы, должны трактовать единственный аргумент '-' как означающий стандартный ввод или стандартный вывод, в зависимости от того, что подходит программе.

Отметим, что многие стандартные программы не следуют всем указанным соглашениям. Главной причиной является историческая совместимость; многие такие программы предшествовали систематизации этих соглашений.

2.1.2. Длинные опции GNU

Как мы видели в разделе 1.4.2 «Поведение программ», программам GNU рекомендуется использовать длинные опции в форме --help, --verbose и т.д. Такие опции, поскольку они начинаются с '--', не конфликтуют с соглашениями POSIX. Их также легче запомнить, и они предоставляют возможность последовательности среди всех утилит GNU. (Например, --help является везде одним и тем же, в отличие от -h для «help», -i для «information» и т.д.) Длинные опции GNU имеют свои собственные соглашения, реализованные в функции getopt_long():

1. У программ, реализующих инструменты POSIX, каждая короткая опция (один символ) должна иметь также свой вариант в виде длинной опции.

2. Дополнительные специфические для GNU опции не нуждаются в соответствующей короткой опции, но мы рекомендуем это сделать.

3. Длинную опцию можно сократить до кратчайшей строки, которая остается уникальной. Например, если есть две опции --verbose и --verbatim, самыми короткими сокращениями будут --verbo и --verba.

4. Аргументы опцииотделяются от длинных опций либо разделителем, либо символом =. Например, --sourcefile=/some/file или --sourcefile /some/file.

5. Опции и аргументы могут быть заинтересованы в операндах командной строки, getopt_long() переставляет аргументы таким образом, что сначала обрабатываются все опции, а затем все операнды доступны последовательно. (Такое поведение можно запретить.)

6. Аргументы опций могут быть необязательными. Для таких опций считается, что аргумент присутствует, если он находится в одной строке с опцией. Это работает лишь для коротких опций. Например, если -х такая опция и дана строка 'foo -хYANKEES -y', аргументом является 'YANKEES'. Для 'foo -х -y' у нет аргументов.

7. Программы могут разрешить длинным опциям начинаться с одной черточки (Это типично для многих программ X Window.)

Многое из этого станет яснее, когда позже в этой главе мы рассмотрим getopt_long().

GNU Coding Standards уделяет значительное место перечислению всех длинных и коротких опций, используемых программами GNU. Если вы пишете программу, использующую длинные опции, посмотрите, нет ли уже использующихся имен опций, которые имело бы смысл использовать и вам.

2.2. Базовая обработка командной строки

Программа на С получает доступ к своим аргументам командной строки через параметры argc и argv. Параметр argc является целым, указывающим число имеющихся аргументов, включая имя команды. Есть два обычных способа определения main(), отличающихся способом объявления argc:

int main(int argc, char *argv[])  int main(int argc, char **argv)

{                                 {

...                                ...

}                                 }

Практически между двумя этими объявлениями нет разницы, хотя первое концептуально более понятно: argc является массивом указателей на символы. А второе определение технически более корректно, это то, что мы используем. На рис. 2.2 изображена эта ситуация.

Рис. 2.2. Память для argc

По соглашению, argv[0] является именем программы. (Детали см. в разделе 9.1.4.3. «Имена программ и argv[0]».) Последующие элементы являются аргументами командной строки. Последним элементом массива argv является указатель NULL.

argc указывает, сколько имеется аргументов; поскольку в С индексы отсчитываются с нуля, выражение 'argv[argc] == NULL' всегда верно. Из-за этого, особенно в коде для Unix, вы увидите различные способы проверки окончания списка аргументов, такие, как цикл с проверкой, что счетчик превысил argc, или 'argv[i] == 0', или '*argv != NULL' и т.д. Они все эквивалентны.

2.2.1. Программа echo V7

Возможно, простейшим примером обработки командной строки является программа V7 echo, печатающая свои аргументы в стандартный вывод, разделяя их пробелами и завершая символом конца строки. Если первым аргументом является -n, завершающий символ новой строки опускается. (Это используется для приглашений из сценариев оболочки.) Вот код[28]:

1  #include <stdio.h>

2

3  main(argc, argv) /*int main(int argc, char **argv)*/

4  int argc;

5  char *argv[];

6  {

7   register int i, nflg;

8

9   nflg = 0;

10  if (argc > 1 && argv[1][0] == && argv[1][1] == 'n') {

11   nflg++;

12   argc--;

13   argv++;

14  }

15  for (i=1; i<argc; i++) {

16   fputs(argv[i], stdout);

17   if (i < argc-1)

18   putchar(' ');

19  }

20  if (nflg == 0)

21   putchar('\n');

22  exit(0);

23 }

Всего 23 строки! Здесь есть два интересных момента. Во-первых, уменьшение argc и одновременное увеличение argv (строки 12 и 13) являются обычным способом пропуска начальных аргументов. Во-вторых, проверка наличия -n (строка 10) является упрощением. -no-newline-at-the-end также работает. (Откомпилируйте и проверьте это!)

Ручной разбор опций обычен для кода V7, поскольку функция getopt() не была еще придумана.

Наконец, здесь и в других местах по всей книге, мы видим использование ключевого слова register. Одно время это ключевое слово давало компилятору подсказку, что данная переменная должна по возможности размещаться в регистре процессора. Теперь это ключевое слово устарело; современные компиляторы все основывают размещение переменных в регистрах на анализе исходного кода, игнорируя ключевое слово register. Мы решили оставить использующий это слово код, как есть, но вы должны знать, что оно больше не имеет реального применения.[29]

2.3. Разбор опций: getopt() и getopt_long()

Примерно в 1980-х группа поддержки Unix для System III в AT&T заметила, что каждая программа Unix использовала для разбора аргументов свои собственные методики. Чтобы облегчить работу пользователей и программистов, они разработали большинство из перечисленных ранее соглашений. (Хотя изложение в System III справки для intro(1) значительно менее формально, чем в стандарте POSIX.)

Группа поддержки Unix разработала также функцию getopt(), вместе с несколькими внешними переменными, чтобы упростить написание кода, придерживающегося стандартных соглашений. Функция GNU getopt_long() предоставляет совместимую с getopt() версию, а также упрощает разбор длинных опций в описанной ранее форме.

2.3.1. Опции с одним символом

Функция getopt() объявлена следующим образом:

#include <unistd.h> /*POSIX*/


int getopt(int argc, char *const argv[], const char *optstring);

extern char *optarg;

extern int optind, opterr, optopt;

Аргументы argc и argv обычно передаются непосредственно от main(). optstring является строкой символов опций. Если за какой-либо буквой в строке следует двоеточие, эта опция ожидает наличия аргумента.

Для использования getopt() вызывайте ее повторно из цикла while до тех пор, пока она не вернет -1. Каждый раз, обнаружив действительный символ опции, функция возвращает этот символ. Если опция принимает аргумент, указатель на него помещается в переменную optarg. Рассмотрим программу, принимающую опцию без аргумента и опцию -b с аргументом:

int ос; /* символ опции */

char *b_opt_arg;

while ((ос = getopt(argc, argv, "ab:")) != -1) {

 switch (oc) {

 case 'a':

  /* обработка -а, установить соответствующий флаг */

  break;

 case 'b':

  /* обработка -b, получить значение аргумента из optarg */

  b_opt_arg = optarg;

  break;

 case ':':

  ... /* обработка ошибок, см. текст */

 case '?':

 default:

  ... /* обработка ошибок, см. текст */

 }

}

В ходе работы getopt() устанавливает несколько переменных, контролирующих обработку ошибок:

char *optarg

Аргумент для опции, если она принимает аргумент.

int optind

Текущий индекс в argv. Когда цикл loop завершается, оставшиеся операнды находятся с argv[optind] по argv[argc-1]. (Помните, что 'argv [argc] ==NULL'.)

int opterr

Когда эта переменная не равна нулю (значение по умолчанию), getopt() печатает свои собственные сообщения для недействительных опций или отсутствующих аргументов опций.

int optopt

Когда находится недействительный символ опции, getopt() возвращает либо '?', либо ':' (см ниже), a optopt содержит обнаруженный недействительный символ.

Люди есть люди, программы неизбежно будут иногда вызываться неправильно либо с недействительной опцией, либо с отсутствующим аргументом опции. Обычно в таких случаях getopt() выводит свои собственные сообщения и возвращает символ '?'. Однако, вы можете изменить такое поведение двумя способами.

Во-первых, записав 0 в opterr перед вызовом getopt(), можно заставить getopt() не предпринимать при обнаружении проблем никаких действий.

Во-вторых, если первый символ в optstring является двоеточием, getopt() не предпринимает никаких действий и возвращает другой символ в зависимости от ошибки следующим образом:

Неверная опция

getopt() возвращает '?', a optopt содержит неверный символ опции (Это обычное поведение).

Отсутствует аргумент опции

getopt() возвращает ':'. Если первый символ optstring не является двоеточием, getopt() возвращает '?', делая этот случай неотличимым от случая неверной опции.

Таким образом, помещение в качестве первого символа optstring двоеточия является хорошей мыслью, поскольку это позволяет различать «неверную опцию» и «отсутствующий аргумент опции». Расплатой за это является то, что getopt() в этом случае также не предпринимает никаких действий, заставляя вас выводить собственные сообщения об ошибках. Вот предыдущий пример, на этот раз с обработкой ошибок:

int ос; /* символ опции */

char *b_opt_arg;

while ((ос = getopt(argc, argv, ":ab:")) != -1) {

 switch (oc) {

 case 'a':

  /* обработка -a, установка соответствующего флага */

  break;

 case 'b':

  /* обработка -b, получение значения аргумента из optarg */

  b_opt_arg = optarg;

  break;

 case ':':

  /* отсутствует аргумент опции */

  fprintf(stderr, "%s: option '-%c' requires an argument\n",

   argv[0], optopt);

  break;

 case '?':

 default:

  /* недействительная опция */

  fprintf(stderr, "%s: option '-%c' is invalid: ignored\n",

   argv[0], optopt);

  break;

 }

}

Замечание о соглашениях по именованию флагов или опций: в большом количестве кода для Unix используются имена в виде xflg для любого данного символа опции x (например, nflg в echo V7; обычным является также xflag). Это может быть замечательным для авторе программы, который без проверки документации знает, что означает опция x. Но это не подходит для кого-то еще, кто пытается прочесть код и не знает наизусть значений всех символов опций. Гораздо лучше использовать имена, передающие смысл опции, как no_newline для опции -n echo.

2.3.2. GNU getopt() и порядок опций

Стандартная функция getopt() прекращает поиск опций, как только встречает аргумент командной строки, который не начинается с GNU getopt() отличается: она просматривает в поисках опций всю командную строку. По мере продвижения она переставляет элементы argv, так что после ее завершения все опции оказываются переставленными в начало, и код, продолжающий разбирать аргументы с argv[optind] до argv[argc-1], работает правильно. Во всех случаях специальный аргумент '--' завершает сканирование опций.

Вы можете изменить поведение по умолчанию, использовав в optstring специальный первый символ следующим образом:

optstring[0] == '+'

GNU getopt() ведет себя, как стандартная getopt(); она возвращает опции по мере их обнаружения, останавливаясь на первом аргументе, не являющемся опцией. Это работает также в том случае, если в окружении присутствует строка POSIXLY_CORRECT.

optstring[0] == '-'

GNU getopt() возвращает каждый аргумент командной строки независимо от того, представляет он аргумент или нет. В этом случае для каждого такого аргумента функция возвращает целое 1, а указатель на соответствующую строку помещает в optarg.

Как и для стандартной getopt(), если первым символом optstring является ':', GNU getopt() различает «неверную опцию» и «отсутствующий аргумент опции», возвращая соответственно '?' или ':'. Символ ':' в optstring может быть вторым символом, если первым символом является '+' или '-'.

Наконец, если за символом опции в optstring следуют два двоеточия, эта опция может иметь необязательный аргумент. (Быстро повторите это три раза!) Такой аргумент считается присутствующим, если он находится в том же элементе argv, что и сама опция, и отсутствующим в противном случае. В случае отсутствия аргумента GNU getopt() возвращает символ опции, а в optarg записывает NULL. Например, пусть имеем:

while ((с = getopt(argc, argv, "ab::")) != -1)

...

для -bYANKEES, возвращаемое значение будет 'b', a optarg указывает на «YANKEES», тогда как для -b или '-b YANKEES' возвращаемое значение будет все то же 'b', но в optarg будет помещен NULL. В последнем случае «YANKEES» представляет отдельный аргумент командной строки.

2.3.3. Длинные опции

Функция getopt_long() осуществляет разбор длинных опций в описанном ранее виде. Дополнительная процедура getopt_long_only() работает идентичным образом, но она используется для программ, в которых все опции являются длинными и начинаются с единичного символа '-'. В остальных случаях обе функции работают точно так же, как более простая функция GNU getopt(). (Для краткости, везде, где мы говорим «getopt_long()», можно было бы сказать «getopt_long() и getopt_long_only()».) Вот объявления функций из справки getopt(3) GNU/Linux:

#include <getopt.h> /* GLIBC */


int getopt_long(int argc, char *const argv[],

 const char *optstring,

 const struct option *longopts, int *longindex);

int getopt_long_only(int argc, char *const argv[],

 const char *optstring,

 const struct option *longopts, int *longindex);

Первые три аргумента те же, что и в getopt(). Следующая опция является указателем на массив struct option, который мы назовем таблицей длинных опций и который вскоре опишем. Параметр longindex, если он не установлен в NULL, указывает на переменную, в которую помешается индекс обнаруженной длинной опции в longopts. Это полезно, например, при диагностике ошибок.

2.3.3.1. Таблица длинных опций

Длинные опции описываются с помощью массива структур struct option. Структура struct option определена в <getopt.h>; она выглядит следующим образом:

struct option {

 const char *name;

 int has_arg;

 int *flag;

 int val;

};

Элементы структуры следующие:

const char *name

Это имя опции без предшествующих черточек, например, «help» или «verbose».

int has_arg

Переменная описывает, имеет ли длинная опция аргумент, и если да, какого вида этот аргумент. Значение должно быть одно из представленных в табл. 2.1. Макроподстановки являются некоторыми символическими именами для числовых значений, приведенных в таблице. Хотя числовые значения тоже работают, макроподстановки гораздо легче читать, и вы должны их использовать вместо соответствующих чисел в любом коде, который пишете.

int *flag

Если этот указатель равен NULL, getopt_long() возвращает значение поля val структуры. Если он не равен NULL, переменная, на которую он указывает, заполняется значением val, a getopt_long() возвращает 0. Если flag не равен NULL, но длинная опция отсутствует, указанная переменная не изменяется.

int val

Если длинная опция обнаружена, это возвращаемое значение или значение для загрузки в *flag, если flag не равен NULL. Обычно, если flag не равен NULL, val является значением true/false, вроде 1 или 0. С другой стороны, если flag равен NULL, val обычно содержит некоторую символьную константу. Если длинная опция соответствует короткой, эта символьная константа должна быть той же самой, которая появляется в аргументе optstring для этой опции. (Все это станет вскоре ясно, когда мы рассмотрим несколько примеров.)


Таблица 2.1. Значения для has_arg

Макроподстановка Числовое значение Смысл
no_argument 0 Опция не принимает аргумент
required_argument 1 Опции требуется аргумент
optional_argument 2 Аргумент опции является необязательным
У каждой длинной опции есть один такой элемент с соответствующими заполненными значениями. В последнем элементе массива все значения должны быть равны нулю. Нет необходимости сортировать массив: getopt_long() осуществляет линейный поиск. Однако, сортировка его по длинным именам может упростить его чтение для программиста.

При первой встрече использование flag и val кажется сбивающим с толку. Давайте сделаем на время шаг назад и рассмотрим, почему это работает именно таким способом В большинстве случаев, обработка опций заключается в установке значений различных флаговых переменных при обнаружении различных символов опций, наподобие этого:

while ((с = getopt(argc, argv, ":af:hv")) != -1) {

 switch (с) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'v':

  do_verbose = 1;

  break;

 ... /* Здесь обработка ошибок */

 }

}

Когда flag не равен NULL, getopt_long() устанавливает значения переменных за вас. Это снижает число операторов case в предыдущем switch с трех до одного. Вот пример таблицы длинных опций и код для работы с ней:

int do_all, do_help, do_verbose; /* флаговые переменные */

char *my_file;

struct option longopts[] = {

 { "all", no_argument, &do_all, 1 },

 { "file", required_argument, NULL, 'f' },

 { "help", no_argument, &do_help, 1 },

 { "verbose", no_argument, &do_verbose, 1 },

 { 0, 0, 0, 0 }

};


while ((с =

 getopt_long(argc, argv, ":f:", longopts, NULL)) != -1) {

 switch (c) {

 case 'f':

  myfile = optarg;

  break;

 case 0:

  /* getopt_long() устанавливает значение переменной,

     просто продолжить выполнение */

  break;

 ... /* Здесь обработка ошибок */

 }

}

Обратите внимание, что значение, переданное аргументу optstring, не содержит больше 'a', 'h' или 'v'. Это означает, что соответствующие короткие опции неприемлемы. Чтобы разрешить как длинные, так и короткие опции, вам придется восстановить в switch соответствующие case из первого примера.

На практике следует писать свои программы так, чтобы у каждой короткой опции была также соответствующая длинная опция. В этом случае проще всего установить в flag NULL, а в val соответствующий единичный символ.

2.3.3.2. Длинные опции в стиле POSIX

Стандарт POSIX резервирует опцию -W для специфических для производителя возможностей. Поэтому по определению -W непереносимо между различными системами.

Если за W в аргументе optstring следует точка с запятой (обратите внимание не двоеточие), getopt_long() рассматривает -Wlongopt так же, как --longopt. Соответственно в предыдущем примере измените вызов следующим образом:

while ((с =

 getopt_long(argc, argv, ":f:W;", longopts, NULL)) != -1) {

С этим изменением -Wall является тем же, что и --all, a -Wfile=myfile тем же, что --file=myfile. Использование точки с запятой позволяет программе использовать при желании -W в качестве обычной опции. (Например, GCC использует ее как нормальную опцию, тогда как gawk использует ее для совместимости с POSIX.)

2.3.3 3. Сводка возвращаемых значений getopt_long()

Теперь должно быть ясно, что getopt_long() предоставляет гибкий механизм для разбора опций. В табл. 2.2 приведена сводка всех возможных возвращаемых значений функции и их значение.


Таблица 2.2. Возвращаемые значения getopt_long()

Возвращаемый код Значение
0 getopt_long() установила флаг, как указано в таблице длинных опций
1 optarg указывает на простой аргумент командной строки
'?' Недействительная опция
' ' Отсутствующий аргумент опции
'x' Символ опции 'x'
-1 Конец опций

Наконец, мы улучшим предыдущий пример кода, показав оператор switch полностью:

int do_all, do_help, do_verbose; /* флаговые переменные */

char *myfile, *user; /* файл ввода, имя пользователя */

struct option longopts[] = {

 { "all", no_argument, &do_all, 1 },

 { "file", required_argument, NULL, 'f'},

 { "help", no_argument, &do_help, 1 },

 { "verbose", no_argument, &do_verbose, 1 },

 { "user" , optional_argument, NULL, 'u'},

 { 0, 0, 0, 0 }

};

...

while((c=getopt_long(argc, argv, ":ahvf:u::W;", longopts, NULL)) != -1) {

 switch (c) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'u':

  if (optarg != NULL)

   user = optarg;

  else

   user = "root";

  break;

 case 'v':

  do_verbose = 1;

  break;

 case 0:

  /* getopt_long() установил переменную, просто продолжить */

  break;

#if 0

 case 1:

  /*

   * Используйте этот case, если getopt_long() должна

   * просмотреть все аргументы. В этом случае добавьте к

   * optstring ведущий * символ '-'. Действительный код,

   * если он есть, работает здесь.

   */

  break;

#endif

 case ':': /* отсутствует аргумент опции */

  fprintf(stderr, "%s: option '-%c' requires an argument\n",

   argv[0], optopt);

  break;

 case '?':

 default: /* недействительная опция */

  fprintf(stderr, "%s: option '-%c' is invalid: ignored\n",

   argv[0], optopt);

  break;

 }

}

В своих программах вы можете захотеть сделать для каждого символа опции комментарии, объясняющие их значение. Однако, если вы использовали описательные имена переменных для каждого символа опции, комментарии уже не так нужны. (Сравните do_verbose и vflag.)

2.3.3.4. GNU getopt() или getopt_long() в программах пользователей

Вы можете захотеть использовать в своих программах GNU getopt() или getopt_long() и заставить их работать на не-Linux системах/ Это нормально; просто скопируйте исходные файлы из программы GNU или из CVS архива библиотеки С GNU (GLIBC)[30]. Исходные файлы getopt.h, getopt.с и getopt1.c. Они лицензированы на условиях меньшей общедоступной лицензии (Lesser General Public License) GNU, которая позволяет включать библиотечные функции даже в патентованные программы. Вы должны включить в свою программу копию файла COPYING.LIB наряду с файлами getopt.h, getopt.с и getopt1.с.

Включите исходные файлы в свой дистрибутив и откомпилируйте их с другими исходными файлами. В исходном коде, вызывающем getopt_long(), используйте '#include <getopt.h>', а не '#include "getopt.h"'. Затем, при компилировании, добавьте к командной строке компилятора С -I. Таким способом сначала будет найдена локальная копия заголовочного файла.

Вы можете поинтересоваться: «Вот так, я уже использую GNU/Linux. Почему я должен включать getopt_long() в свой исполняемый модуль, увеличивая его размер, если процедура уже находится в библиотеке С?» Это хороший вопрос. Однако, здесь не о чем беспокоиться. Исходный код построен так, что если он компилируется на системе, которая использует GLIBC, откомпилированные файлы не будут содержать никакого кода! Вот подтверждение на нашей системе:

$ uname -а /* Показать имя и тип системы */

Linux example 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux

$ ls -l getopt.о getopt1.о /* Показать размеры файлов */

-rw-r--r-- 1 arnold devel 9836 Mar 24 13:55 getopt.о

-rw-r--r-- 1 arnold devel 10324 Mar 24 13:55 getopt1.о

$ size getopt.о getopt1.о /* Показать включенные в исполняемый

модуль размеры */

text data bss dec hex filename

0 0 0 0 0 getopt.о

0 0 0 0 0 getopt1.о

Команда size печатает размеры различных составных частей двоичного объекта или исполняемого файла. Мы объясним вывод в разделе 3.1 «Адресное пространство Linux/Unix». Что важно понять прямо сейчас, это то, что несмотря на ненулевой размер самих файлов, они не вносят никакого вклада в конечный исполняемый модуль. (Думаем, это достаточно ясно.)

2.4. Переменные окружения

Окружение представляет собой набор пар вида 'имя=значение' для каждой программы. Эти пары называются переменными окружения. Каждое имя состоит от одной до любого числа буквенно-цифровых символов или символов подчеркивания ('_'), но имя не может начинаться с цифры. (Это правило контролируется оболочкой; С API может помешать в окружение все, что захочет, за счет возможного запутывания последующих программ.)

Переменные окружения часто используются для управления поведением программ. Например, если в окружении существует POSIXLY_CORRECT, многие программы запрещают расширения или историческое поведение, которые несовместимы со стандартом POSIX.

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

Конечно, недостатком использования переменных окружения является то, что они могут молча изменять поведение программы. Джим Мейеринг (Jim Meyering), сопроводитель Coreutils, выразил это таким образом:

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

2.4.1. Функции управления окружением

Несколько функций позволяют получать значения переменных окружения, изменять эти значения или удалять их. Вот соответствующие объявления:

#include <stdlib.h>


char *getenv(const char *name);

/* ISO С: Получить переменную

   окружения */

int setenv(const char *name, /* POSIX: Установить переменную */

           const char *value, /* окружения */

           int overwrite);

int putenv(char *string); /* XSI: Установить переменную

                             окружения, использует строку */

void unsetenv(const char *name); /* POSIX: Удалить переменную

                                    окружения */

int clearenv(void); /* Общее: очистить все окружение */

Функция getenv() — та, которую вы будете использовать в 99% случаев. Ее аргументом является имя переменной окружения, которую нужно искать, такое, как «НОМЕ» или «PATH». Если переменная существует, getenv() возвращает указатель на строковое значение. Если нет, возвращается NULL. Например:

char *pathval;

/* Поиск PATH; если нет, использовать значение

   по умолчанию */

if ((pathval = getenv("PATH")) == NULL)

 pathval = "/bin:/usr/bin:/usr/ucb";

Иногда переменная окружения существует, но с пустым значением. В этом случае возвращаемое значение не равно NULL, но первый символ, на которую оно указывает, будет нулевым байтом, который в С является символом конца строки, '\0'. Ваш код должен позаботиться проверить, что возвращаемое значение не равно NULL. Если оно не NULL, необходимо также проверить, что строка не пустая, если вы хотите для чего-то использовать значение переменной. В любом случае, не используйте возвращенное значение слепо.

Для изменения переменной окружения или добавления к окружению еще одной используется setenv():

if (setenv("PATH", "/bin:/usr/bin:/usr/ucb", 1) != 0) {

 /* обработать ошибку */

}

Возможно, что переменная уже существует в окружении. Если третий аргумент равен true (не ноль), новое значение затирает старое. В противном случае, предыдущее значение не меняется. Возвращаемое значение равно -1, если для новой переменной не хватило памяти, и 0 в противном случае. setenv() для сохранения в окружении делает индивидуальные копии как имени переменной, так и нового ее значения

Более простой альтернативой setenv() является putenv(), которая берет одну строку «имя=значение» и помещает ее в окружение:

if (putenv("PATH=/bin:/usr/bin:/usr/ucb") != 0) {

 /* обработать ошибку */

}

putenv() слепо заменяет любые предшествующие значения для той же переменной. А также, и это, возможно, более важно, строка, переданная putenv(), помещается непосредственно в окружение. Это означает, что если ваш код позже изменит эту строку (например, если это был массив, а не строковая константа), окружение также будет изменено. Это, в свою очередь, означает, что вам не следует использовать в качестве параметров для putenv() локальную переменную. По всем этим причинам setenv() является более предпочтительной функцией.

ЗАМЕЧАНИЕ. GNU putenv() имеет дополнительную (документированную) особенность в своем поведении. Если строка аргумента является именем без следующего за ним символа =, именованная переменная удаляется. Программа GNU env, которую мы рассмотрим далее в мой главе, полагается на такое поведение.

Функция unsetenv() удаляет переменную из окружения:

unsetenv("PATH");

Наконец, функция clearenv() полностью очищает окружение:

if (clearenv() != 0) {

 /* обработать ошибку */

}

Эта функция не стандартизирована POSIX, хотя она доступна в GNU/Linux и нескольких коммерческих вариантах Unix. Ее следует использовать, если приложение должно быть очень безопасным и нужно построить собственное окружение с нуля. Если clearenv() недоступна, в справке GNU/Linux для clearenv(3) рекомендуется использовать для выполнения этой задачи 'environ = NULL'.

2.4.2. Окружение в целом: environ

Правильным способом работы с окружением является использование функций, описанных в предыдущем разделе. Однако, стоит взглянуть на то, как это работает «под капотом».

Внешняя переменная environ предоставляет доступ таким же способом, как argv предоставляет доступ к аргументам командной строки. Вы сами должны объявить переменную. Хотя она и стандартизирована POSIX, environ намеренно не объявлена ни в одном стандартном заголовочном файле (Это, кажется, прослеживается из исторической практики.) Вот объявление:

extern char **environ; /* Смотрите, нет заголовочного файла POSIX */

Как и в argv, завершающим элементом environ является NULL. Однако, здесь нет переменной «числа строк окружения», которая соответствовала бы argc. Следующая простая программа распечатывает все окружение:

/* ch02-printenv.c --- Распечатать окружение. */

#include <stdio.h>


extern char **environ;

int main(int argc, char **argv) {

 int i;

 if (environ != NULL)

  for (i = 0; environ[i] != NULL; i++)

   printf("%s\n", environ[i]);

 return 0;

}

Хотя это и маловероятно, перед попыткой использовать environ эта программа проверяет, что она не равна NULL.

Переменные хранятся в окружении в случайном порядке. Хотя некоторые оболочки Unix хранят переменные окружения в отсортированном по именам переменных виде, это формально не требуется, и многие оболочки не сортируют их.

В качестве уловки реализации можно получить доступ к окружению, объявив третий параметр main():

int main(int argc, char **argv, char **envp) {

 ...

}

Затем можно использовать envp также, как environ. Хотя это иногда можно увидеть в старом коде, мы не рекомендуем такое использование; environ является официальным, стандартным, переносимым способом получения доступа ко всему окружению, если это вам необходимо.

2.4.3. GNU env

Чтобы завершить главу, рассмотрим GNU версию команды env. Эта команда добавляет переменные к окружению в ходе выполнения одной команды. Она может использоваться также для очищения окружения в ходе этой команды или для удаления отдельных переменных окружения. Программа обеспечивает нас двойной функциональностью, поскольку проявляет возможности как getopt_long(), так и несколько других возможностей, обсуждавшихся в этом разделе. Вот как вызывается программа:

$ env --help

Usage: env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

/* Устанавливает соответствующее VALUE для каждого NAME и запускает COMMAND */

-i, --ignore-environment /* запустить с пустым окружением */

-u, --unset=NAME         /* удалить переменную из окружения */

--help                   /* показать этот экран справки и выйти */

--version                /* вывести информацию о версии и выйти */

/* Простое - предполагает -1. Если не указана COMMAND, отображает

   имеющееся окружение.

Об ошибках сообщайте в <bug-coreutils@gnu.org>. */

Вот несколько примеров вызовов команды:

$ env - myprog arg1 /* Очистить окружение, запустить программу с args */

$ env - РАТН=/bin:/usr/bin myprog arg1 /* Очистить окружение, добавить PATH, запустить программу */

$ env -u IFS PATH=/bin:/usr/bin myprog arg1 /* Сбросить IFS, добавить PATH, запустить программу */

Код начинается со стандартной формулировки авторских прав GNU и разъясняющего комментария. Мы для краткости их опустили. (Формулировка авторского права обсуждается в Приложении С «Общедоступная лицензия GNU». Показанного ранее вывода --help достаточно для понимания того, как работает программа.) За объявленным авторским правом и комментарием следуют подключаемые заголовочные файлы и объявления. Вызов макроса 'N_("string")' (строка 93) предназначен для использования при локализации программного обеспечения, тема, освещенная в главе 13 «Интернационализация и локализация». Пока вы можете рассматривать его, как содержащий строковую константу.

80  #include <config.h>

81  #include <stdio.h>

82  #include <getopt.h>

83  #include <sys/types.h>

84  #include <getopt.h>

85

86  #include "system.h"

87  #include "error.h"

88  #include "closeout.h"

89

90  /* Официальное имя этой программы (напр., нет префикса 'g'). */

91  #define PROGRAM_NAME "env"

92

93  #define AUTHORS N_ ("Richard Mlynarik and David MacKenzie")

94

95  int putenv();

96

97  extern char **environ;

98

99  /* Имя, посредством которого эта программа была запущена. */

100 char *program_name;

101

102 static struct option const longopts[] =

103  {

104  {"ignore-environment", no_argument, NULL, 'i'},

105  {"unset", required_argument, NULL, 'u'},

106  {GETOPT_HELP_OPTION_DECL},

107  {GETOPT_VERSION_OPTION_DECL},

108  {NULL, 0, NULL, 0}

109 };

GNU Coreutils содержит большое число программ, многие из которых выполняют одни и те же общие задачи (например, анализ аргументов). Для облегчения сопровождения многие типичные идиомы были определены в виде макросов. Двумя таким макросами являются GETOPT_HELP_OPTION_DECL и GETOPT_VERSION_OPTION (строки 106 и 107). Вскоре мы рассмотрим их определения. Первая функция, usage(), выводит информацию об использовании и завершает программу. Макрос _("string") (строка 115, используется также по всей программе) также предназначен для локализации, пока также считайте его содержащим строковую константу.

111 void

112 usage(int status)

113 {

114  if (status '= 0)

115   fprintf(stderr, _("Try '%s --help' for more information.\n"),

116    program_name);

117  else

118  {

119   printf (_("\

120    Usage: %s [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]\n"),

121    program_name);

122   fputs (_("\

123    Set each NAME to VALUE in the environment and run COMMAND. \n\

124    \n\

125    -i, --ignore-environment start with an empty environment\n\

126    -u, --unset=NAME remove variable from the environment\n\

127    "), stdout);

128   fputs(HELP_OPTION_DESCRIPTION, stdout);

129   fputs(VERSION_OPTION_DESCRIPTION, stdout);

130   fputs(_("\

131    \n\

132    A mere - implies -i. If no COMMAND, print the resulting\

133    environment.\n"), stdout);

134   printf(_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);

135  }

136  exit(status);

137 }

Первая часть main() объявляет переменные и настраивает локализацию. Функции setlocale(), bindtextdomain() и textdomain() (строки 147–149) обсуждаются в главе 13 «Интернационализация и локализация». Отметим, что эта программа использует аргумент main() envp (строка 140). Это единственная программа Coreutils, которая так делает. Наконец, вызов atexit() в строке 151 (см. раздел 9.1.5.3. «Функции завершения») регистрирует библиотечную функцию Coreutils, которая очищает все выходные буферы и закрывает stdout, выдавая сообщение при ошибке. Следующая часть программы обрабатывает аргументы командной строки, используя getopt_long().

139 int

140 main(register int argc, register char **argv, char **envp)

141 {

142  char *dummy_environ[1];

143  int optc;

144  int ignore_environment = 0;

145

146  program_name = argv[0];

147  setlocale(LC_ALL, "");

148  bindtextdomain(PACKAGE, LOCALEDIR);

149  textdomain(PACKAGE);

150

151  atexit(close_stdout);

152

153  while ((optc = getopt_long(argc, argv, "+iu:", longopts, NULL)) != -1)

154  {

155   switch (optc)

156   {

157   case 0:

158    break;

159   case 'i':

160    ignore_environment = 1;

161    break;

162   case 'u':

163    break;

164   case_GETOPT_HELP_CHAR;

165   case_GETOPT_VERSION_CHAR(PROGRAM_NAME, AUTHORS);

166   default:

167    usage(2);

168   }

169  }

170

171  if (optind != argc && !strcmp(argv[optind], "-"))

172   ignore_environment = 1;

Вот отрывок из файла src/sys2.h в дистрибутиве Coreutils с упомянутыми ранее определениями и макросом 'case_GETOPT_xxx', использованным выше (строки 164–165):

/* Вынесение за скобки общей части кода, обрабатывающего --help и

   --version. */

/* Эти значения перечисления никак не могут конфликтовать со значениями опций,

   обычно используемыми командами, включая CHAR_MAX + 1 и т.д. Избегайте

   CHAR_MIN - 1, т.к. оно может равняться -1, значение завершения опций getopt.

*/

enum {

 GETOPT_HELP_CHAR = (CHAR_MIN — 2),

 GETOPT_VERSION_CHAR = (CHAR_MIN - 3)

};

#define GETOPT_HELP_OPTION_DECL \

 "help", no_argument, 0, GETOPT_HELP_CHAR

#define GETOPT_VERSION_OPTION_DECL \

 "version", no_argument, 0, GETOPT_VERSION_CHAR

#define case_GETOPT_HELP_CHAR \

 case GETOPT_HELP_CHAR: \

  usage(EXIT_SUCCESS); \

  break;

#define case_GETOPT_VERSION_CHAR(Program_name, Authors) \

 case GETOPT_VERSION_CHAR: \

  version_etc(stdout, Program_name, PACKAGE, VERSION, Authors); \

  exit(EXIT_SUCCESS); \

  break;

Результатом этого кода является печать сообщения об использовании утилиты для --help и печать информации о версии для --version. Обе опции завершаются успешно («Успешный» и «неудачный» статусы завершения описаны в разделе 9.1.5.1 «Определение статуса завершения процесса».) Поскольку в Coreutils входят десятки утилит, имеет смысл вынести за скобки и стандартизовать как можно больше повторяющегося кода.

Возвращаясь к env.с:

174 environ = dummy_environ;

175 environ[0] = NULL;

176

177 if (!ignore_environment)

178  for (; *envp; envp++)

179   putenv(*envp);

180

181 optind = 0; /* Принудительная реинициализация GNU getopt. */

182 while ((optc = getopt_long(argc, argv, "+iu:", longopts, NULL)) != -1)

183  if (optc == 'u')

184   putenv(optarg); /* Требуется GNU putenv. */

185

186 if (optind !=argc && !strcmp(argv[optind], "-")) /* Пропустить опции */

187  ++optind;

188

189 while (optind < argc && strchr(argv[optind], '=')) /* Установить

     переменные окружения * /

190 putenv(argv[optind++]);

191

192 /* Если программа не указана, напечатать переменные окружения и выйти. */

193 if (optind == argc)

194 {

195  while (*environ)

196   puts (*environ++);

197  exit(EXIT_SUCCESS);

198 }

Строки 174–179 переносят существующие переменные в новую копию окружения. В глобальную переменную environ помещается указатель на пустой локальный массив. Параметр envp поддерживает доступ к первоначальному окружению.

Строки 181–184 удаляют переменные окружения, указанные в опции -u. Программа осуществляет это, повторно сканируя командную строку и удаляя перечисленные там имена. Удаление переменных окружения основывается на обсуждавшейся ранее особенности GNU putenv(): при вызове с одним лишь именем переменной (без указанного значения) putenv() удаляет ее из окружения.

После опций в командной строке помещаются новые или замещающие переменные окружения. Строки 189–190 продолжают сканирование команднойстроки, отыскивая установки переменных окружения в виде 'имя=значение'.

По достижении строки 192, если в командной строке ничего не осталось, предполагается, что env печатает новое окружение и выходит из программы. Она это и делает (строки 195–197).

Если остались аргументы, они представляют имя команды, которую нужно вызвать, и аргументы для передачи этой новой команде. Это делается с помощью системного вызова execvp() (строка 200), который замещает текущую программу новой. (Этот вызов обсуждается в разделе 9.1.4 «Запуск новой программы: семейство exec()»; пока не беспокойтесь о деталях.) Если этот вызов возвращается в текущую программу, он потерпел неудачу. В таком случае env выводит сообщение об ошибке и завершает программу.

200  execvp(argv[optind], &argv[optind]);

201

202  {

203   int exit_status = (errno == ENOENT ? 127 : 126);

204   error(0, errno, "%s", argv[optind]);

205   exit(exit_status);

206  }

207 }

Значения кода завершения 126 и 127 (определяемые в строке 203) соответствуют стандарту POSIX. 127 означает, что программа, которую execvp() попыталась запустить, не существует. (ENOENT означает, что файл не содержит записи в каталоге.) 126 означает, что файл существует, но была какая-то другая ошибка.

2.5. Резюме

• Программы на С получают аргументы своей командной строки через параметры argc и argv. Функция getopt() предоставляет стандартный способ для последовательного разбора опций и их аргументов GNU версия getopt() предоставляет некоторые расширения, a getopt_long() и getopt_long_only() дает возможность легкого разбора длинных опций.

• Окружение представляет собой набор пар 'имя=значение', который каждая программа наследует от своего родителя. Программы могут по прихоти своего автора использовать для изменения своего поведения переменные окружения, в дополнение к любым аргументам командной строки. Для получения значений переменных окружения, изменения их значений или удаления существуют стандартные процедуры (getenv(), setenv(), putenv() и unsetenv()). При необходимости можно получить доступ ко всему окружению через внешнюю переменную environ или через третий аргумент char **envp функции main(). Последний способ не рекомендуется.

Упражнения

1. Предположим, что программа принимает опции -a, -b и , и что -b требует наличия аргумента. Напишите для этой программы код ручного разбора аргументов без использования getopt() или getopt_long(). Для завершения обработки опций принимается --. Убедитесь, что -ас работает, также, как -bYANKEES, -b YANKEES и -abYANKEES. Протестируйте программу.

2. Реализуйте getopt(). Для первой версии вы можете не беспокоиться насчет случая 'optstring[0] == ':''. Можете также игнорировать opterr.

3. Добавьте код для 'optstring[0] == ':'' и opterr к своей версии getopt().

4. Распечатайте и прочтите файлы GNU getopt.h, getopt.с и getopt1.с.

5. Напишите программу, которая объявляет как environ, так и envp, и сравните их значения.

6. Разбор аргументов командной строки и опций является тем колесом, которое многие люди не могут не изобретать вновь. Вы можете захотеть познакомиться с различными анализирующими аргументы пакетами, помимо getopt() и getopt_long(), такими, как:

 • библиотека анализа аргументов Plan 9 From Bell Labs arg(2)[31],

 • Argp[32],

 • Argv[33],

 • Autoopts[34],

 • GNU Gengetopt[35],

 • Opt[36],

 • Popt[37]. См. также справочную страницу popt(3) системы GNU/Linux.

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

Глава 3 Управление памятью на уровне пользователя

Без памяти для хранения данных программа не может выполнить никакую работу (Или, скорее, невозможно выполнить никакую полезную работу.) Реальные программы не могут позволить себе полагаться на буферы и массивы структур данных фиксированного размера. Они должны быть способны обрабатывать вводимые данные различных размеров, от незначительных до больших. Это, в свою очередь, ведет к использованию динамически выделяемой памяти — памяти, выделяемой в ходе исполнения, а не при компиляции. Вот как вводится в действие принцип GNU «никаких произвольных ограничений».

Поскольку динамически выделяемая память является основным строительным блоком для реальных программ, мы рассмотрим этот вопрос в начале, до рассмотрения всего остального. Наше обсуждение фокусируется на рассмотрении процесса и его памяти исключительно на уровне пользователя; оно не имеет ничего общего с архитектурой процессора.

3.1. Адресное пространство Linux/Unix

В качестве рабочего определения мы приняли, что процесс является запушенной программой. Это означает, что операционная система загрузила исполняемый файл для этой программы в память, сделала доступными аргументы командной строки и переменные окружения и запустила ее. Процесс имеет пять выделенных для него концептуально различных областей памяти:

Код

Часто называемая сегментом текста область, в которой находятся исполняемые инструкции. Linux и Unix организуют вещи таким образом, что несколько запушенных экземпляров одной программы по возможности разделяют свой код; в любое время в памяти находится лишь одна копия инструкций одной и той же программы (Это прозрачно для работающих программ.) Часть исполняемого файла, содержащая сегмент текста, называется секцией текста.

Инициализированные данные

Статически выделенные и глобальные данные, которые инициализированы ненулевыми значениями, находятся в сегменте данных. У каждого процесса с одной и той же запущенной программой свой собственный сегмент данных. Часть исполняемого файла, содержащая сегмент данных, является секцией данных.

Инициализированные нулями данные[38]

Глобальные и статически выделенные данные, которые по умолчанию инициализированы нулями, хранятся в области процесса, который называют областью BSS[39]. У каждого процесса, в котором запущена одна и та же программа, своя область BSS. При запуске данные BSS помещаются в сегмент данных. В исполняемом файле они хранятся в секции BSS.

Формат исполняемого файла Linux/Unix таков, что пространство исполняемого файла на диске занимают лишь переменные, инициализированные ненулевыми значениями. Поэтому большой массив, объявленный как 'static char somebuf[2048];', который автоматически заполняется нулями, не занимает 2 Кб пространства на диске. (Некоторые компиляторы имеют опции, позволяющие вам помещать инициализированные нулями данные в сегмент данных.)

Куча (heap)

Куча является местом, откуда выделяется динамическая память (получаемая с помощью функции malloc() и подобными ей). Когда из кучи выделяется память, адресное пространство процесса растет, что вы можете заметить, отслеживая запущенный процесс с помощью команды ps.

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

Для кучи характерен «рост вверх». Это означает, что последовательные элементы, добавляемые к куче, добавляются по адресам, численно превосходящим предыдущие. Куча обычно начинается сразу после области BSS сегмента данных.

Стек

Сегмент стека — это область, в которой выделяются локальные переменные. Локальными являются все переменные, объявленные внутри левой открывающей фигурной скобки тела функции (или другой левой фигурной скобки) и не имеющие ключевого слова static.

В большинстве архитектур параметры функций также помещаются в стек наряду с «невидимой» учетной информацией, генерируемой компилятором, такой, как возвращаемое функцией значение и адрес возврата для перехода из функции к месту, откуда произошел вызов. (В некоторых архитектурах для этого используются регистры.) Именно использование стека для параметров функций и возвращаемых ими значений делает удобным написание рекурсивных функций (тех, которые вызывают сами себя) Переменные, хранящиеся в стеке, «исчезают», когда функция, их содержащая, возвращается, пространство стека используется повторно для последующих вызовов функций. В большинстве современных архитектур стек «растет вниз», это означает, что элементы, находящиеся глубже в цепи вызова, находятся по численно меньшим адресам. В работающей программе области инициализированных данных, BSS и кучи обычно размещаются в единой протяженной области: сегменте данных. Сегменты стека и кода отделены от сегмента данных и друг от друга. Это показано на рис. 3.1.

Рис. 3.1. Адресное пространство Linux/Unix

Хотя перекрывание стека и кучи теоретически возможно, операционная система предотвращает этот случай, и любая программа, пытающаяся это сделать, напрашивается на неприятности. Это особенно верно для современных систем, в которых адресные пространства большие и интервал между верхушкой стека и концом кучи значителен. Различные области памяти могут иметь различную установленную на память аппаратную защиту. Например, сегмент текста может быть помечен «только для исполнения», тогда как у сегментов данных и стека разрешение на исполнение может отсутствовать. Такая практика может предотвратить различные виды атак на безопасность. Подробности, конечно, специфичны для оборудования и операционной системы, и они могут со временем меняться. Стоит заметить, что стандартные как С, так и C++ позволяют размещать элементы с атрибутом const в памяти только для чтения. Сводка взаимоотношений различных сегментов приведена в табл. 3.1.


Таблица 3.1. Сегменты исполняемой программы и их размещение

Память программы Сегмент адресного пространства Секция исполняемого файла
Код Text Text
Инициализированные данные Data Data
BSS Data BSS
Куча Data
Стек Stack
Программа size распечатывает размеры в байтах каждой из секций text, data и BSS вместе с общим размером в десятичном и шестнадцатеричном виде. (Программа ch03-memaddr.с показана далее в этой главе; см. раздел 3.2.5 «Исследование адресного пространства».)

$ cc -o ch03-memaddr.с -о ch03-memaddr /* Компилировать программу */

$ ls -l ch03-memaddr /* Показать общий размер */

-rwxr-xr-x 1 arnold devel 12320 Nov 24 16:45 ch03-memaddr

$ size ch03-memaddr /* Показать размеры компонентов */

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr


$ strip ch03-memaddr /* Удалить символы */

$ ls -l ch03-memaddr /* Снова показать общий размер */

-rwxr-xr-x 1 arnold devel 3480 Nov 24 16:45 ch03-memaddr

$ size ch03-memaddr /* Размеры компонентов не изменились */

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr

Общий размер загруженного в память из файла в 12 320 байтов всего лишь 1742 байта. Большую часть этого места занимают символы (symbols), список имен переменных и функций программы. (Символы не загружаются в память при запуске программы.) Программа strip удаляет символы из объектного файла. Для большой программы это может сохранить значительное дисковое пространство ценой невозможности отладки дампа ядра[40], если таковой появится (На современных системах об этом не стоит беспокоиться, не используйте strip.) Даже после удаления символов файл все еще больше, чем загруженный в память образ, поскольку формат объектного файла содержат дополнительные данные о программе, такие, как использованные разделяемые библиотеки, если они есть.[41]

Наконец, упомянем потоки (threads), которые представляют несколько цепочек исполнения в рамках единственного адресного пространства. Обычно у каждого потока имеется свой собственный стек, а также способ получения локальных данных потока, т.е. динамически выделяемых данных для персонального использования этим потоком. Мы больше не будем рассматривать в данной книге потоки, поскольку это является продвинутой темой.

3.2. Выделение памяти

Четыре библиотечные функции образуют основу управления динамической памятью С Мы опишем сначала их, затем последуют описания двух системных вызовов, поверх которых построены эти библиотечные функции. Библиотечные функции С, в свою очередь, обычно используются для реализации других выделяющих память библиотечных функций и операторов C++ new и delete.

Наконец, мы обсудим функцию, которую часто используют, но которую мы не рекомендуем использовать.

3.2.1. Библиотечные вызовы: malloc(), calloc(), realloc(), free()

Динамическую память выделяют с помощью функций malloc() или calloc(). Эти функции возвращают указатели на выделенную память. Когда у вас есть блок памяти определенного первоначального размера, вы можете изменить его размер с помощью функции realloc(). Динамическая память освобождается функцией free().

Отладка использования динамической памяти сама по себе является важной темой. Инструменты для этой цели мы обсудим в разделе 15.5.2 «Отладчики выделения памяти».

3.2.1.1. Исследование подробностей на языке С

Вот объявления функций из темы справки GNU/Linux malloc(3):

#include <stdlib.h> /* ISO С */


void *calloc(size_t nmemb, size_t size);

 /* Выделить и инициализировать нулями */

void *malloc(size_t size);

 /* Выделить без инициализации */

void free(void *ptr);

 /* Освободить память */

void *realloc(void *ptr, size_t size);

 /* Изменить размер выделенной памяти */

Функции выделения памяти возвращают тип void*. Это бестиповый или общий указатель, все, что с ним можно делать — это привести его к другому типу и назначить типизированному указателю. Примеры впереди.

Тип size_t является беззнаковым целым типом, который представляет размер памяти. Он используется для динамического выделения памяти, и далее в книге мы увидим множество примеров его использования. На большинстве современных систем size_t является unsigned long, но лучше явно использовать size_t вместо простого целого типа unsigned.

Тип ptrdiff_t используется для вычисления адреса в арифметике указателей, как в случае вычисления указателя в массиве:

#define MAXBUF ...

char *p;

char buf[MAXBUF];

ptrdiff_t where;


p = buf;

while (/* некоторое условие */) {

 ...

 p += something;

 ...

 where = p - buf; /* какой у нас индекс? */

}

Заголовочный файл <stdlib.h> объявляет множество стандартных библиотечных функций С и типов (таких, как size_t), он определяет также константу препроцессора NULL, которая представляет «нуль» или недействительный указатель. (Это нулевое значение, такое, как 0 или '((void*)0)'. Явное использование 0 относится к стилю С++; в С, однако, NULL является предпочтительным, мы находим его гораздо более читабельным для кода С.)

3.2.1.2. Начальное выделение памяти: malloc()

Сначала память выделяется с помощью malloc(). Передаваемое функции значение является общим числом затребованных байтов. Возвращаемое значение является указателем на вновь выделенную область памяти или NULL, если память выделить невозможно. В последнем случае для обозначения ошибки будет установлен errno. (errno является специальной переменной, которую системные вызовы и библиотечные функции устанавливают для указания произошедшей ошибки. Она описывается в разделе 4.3 «Определение ошибок».) Например, предположим, что мы хотим выделить переменное число некоторых структур. Код выглядит примерно так:

struct coord { /* 3D координаты */

 int x, y, z;

} *coordinates;

unsigned int count; /* сколько нам нужно */

size_t amount; /* общий размер памяти */

/* ... как-нибудь определить нужное число... */

amount = count * sizeof(struct coord); /* сколько байт выделить */

coordinates = (struct coord*)malloc(amount); /* выделить память */

if (coordinates == NULL) {

 /* сообщить об ошибке, восстановить или прервать */

}

/* ... использовать координаты... */

Представленные здесь шаги являются стереотипными. Порядок следующий:

1. Объявить указатель соответствующего типа для выделенной памяти.

2. Вычислить размер выделяемой памяти в байтах. Для этого нужно умножить число нужных объектов на размер каждого из них. Последний получается с помощью оператора С sizeof, который для этой цели и существует (наряду с другими). Таким образом, хотя размер определенной структуры среди различных компиляторов и архитектур может различаться, sizeof всегда возвращает верное значение, а исходный код остается правильным и переносимым.

При выделении массивов для строк символов или других данных типа char нет необходимости умножения на sizeof(char), поскольку последнее по определению всегда равно 1. Но в любом случае это не повредит.

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

Обратите внимание, что на C++ присвоение знамения указателя одного типа указателю другого типа требует приведения типов, какой бы ни был контекст. Для управления динамической памятью программы C++ должны использовать new и delete, а не malloc() и free(), чтобы избежать проблем с типами.

4. Проверить возвращенное значение. Никогда не предполагайте, что выделение памяти было успешным. Если выделение памяти завершилось неудачей, malloc() возвращает NULL. Если вы используете значение без проверки, ваша программа может быть немедленно завершена из-за нарушения сегментации (segmentation violation), которое является попыткой использования памяти за пределами своего адресного пространства.

Если вы проверите возвращенное значение, вы можете по крайней мере выдать диагностическое сообщение и корректно завершить программу. Или можете попытаться использовать какой-нибудь другой способ восстановления.

Выделив блок памяти и установив в coordinates указатель на него, мы можем затем интерпретировать coordinates как массив, хотя он в действительности указатель:

int cur_x, cur_y, cur_z;

size_t an_index;

an_index = something;

cur_x = coordinates[an_index].x;

cur_y = coordinates[an_index].y;

cur_z = coordinates[an_index].z;

Компилятор создает корректный код для индексирования через указатель при получении доступа к членам структуры coordinates[an_index].

ЗАМЕЧАНИЕ. Блок памяти, возвращенный malloc(), не инициализирован. Он может содержать любой случайный мусор. Необходимо сразу же инициализировать память нужными значениями или хотя бы нулями. В последнем случае используйте функцию memset() (которая обсуждается в разделе 12.2 «Низкоуровневая память, функции memXXX()):

memset(coordinates, '\0', amount);

Другой возможностью является использование calloc(), которая вскоре будет описана.

Джефф Колье (Geoff Collyer) рекомендует следующую методику для выделения памяти:

some_type *pointer;

pointer = malloc(count * sizeof(*pointer));

Этот подход гарантирует, что malloc() выделит правильное количество памяти без необходимости смотреть объявление pointer. Если тип pointer впоследствии изменится, оператор sizeof автоматически гарантирует, что выделяемое число байтов остается правильным. (Методика Джеффа опускает приведение типов, которое мы только что обсуждали. Наличие там приведения типов также гарантирует диагностику, если тип pointer изменится, а вызов malloc() не будет обновлен.)

3.2.1.3. Освобождение памяти: free()

Когда вы завершили использование памяти, «верните ее обратно», используя функцию free(). Единственный аргумент является указателем, предварительно полученным с использованием другой функции выделения. Можно (хотя это бесполезно) передать функции free() пустой указатель:

free(coordinates);

coordinates = NULL; /* не требуется, но хорошая мысль */

После вызова free(coordinates) доступ к памяти, на которую указывает coordinates, запрещен. Она теперь «принадлежит» процедурам выделения, и они могут поступать с ней как сочтут нужным. Они могут изменить содержимое памяти или даже удалить ее из адресного пространства процесса! Таким образом, есть несколько типичных ошибок, которых нужно остерегаться при использовании free():

Доступ к освобожденной памяти

Если она не была освобождена, переменная coordinates продолжает указывать на блок памяти, который больше не принадлежит приложению. Это называется зависшим указателем (dangling pointer). На многих системах вы можете уйти от наказания, продолжая использовать эту память, по крайней мере до следующего выделения или освобождения памяти. На других системах, однако, такой доступ не будет работать. В общем, доступ к освобожденной памяти является плохой мыслью: это непереносимо и ненадежно, и GNU Coding Standards отвергает его. По этой причине неплохо сразу же установить в указателе программы значение NULL. Если затем вы случайно попытаетесь получить доступ к освобожденной памяти, программа немедленно завершится с ошибкой нарушения сегментации (надеемся, до того, как вы успели вашу программу выпустить в свет).

Освобождение одного и того же указателя дважды

Это создает «неопределенное поведение». После передачи блока памяти обратно выделяющим процедурам они могут объединить освобожденный блок с другой свободной памятью, которая есть в их распоряжении. Освобождение чего-то уже освобожденного ведет к неразберихе и в лучшем случае к крушению; известно, что так называемые двойные освобождения приводили к проблемам безопасности.

Передача указателя, полученного не от функций malloc(), calloc() или realloc()

Это кажется очевидным, но тем не менее важно. Плоха даже передача указателя на адрес где-то в середине динамически выделенной памяти:

free(coordinates + 10);

/* Освободить все кроме первых 10 элементов */

Этот вызов не будет работать и, возможно, приведет к пагубным последствиям, таким как крушение. (Это происходит потому, что во многих реализациях malloc() «учетная» информация хранится перед возвращенными данными. Когда free() пытается использовать эту информацию, она обнаружит там недействительные данные. В других реализациях, где учетная информация хранится в конце выделенного блока; возникают те же проблемы.)

Выход за пределы буфера

Доступ к памяти за пределами выделенного блока также ведет к неопределенному поведению, опять из-за того, что она может содержать учетную информацию или, возможно, вообще не принадлежать адресному пространству процесса. Запись в такой участок памяти гораздо хуже, поскольку это может уничтожить учетные данные.

Отказ в освобождении памяти

Любая динамическая память, которая больше не нужна, должна быть освобождена. В частности, необходимо тщательно управлять памятью и освобождать ее, когда она выделяется внутри циклов или рекурсивных или глубоко вложенных вызовов функций. Отказ от этого ведет к утечкам памяти, при которых память процесса может неограниченно расти; в конце концов, процесс завершается из-за нехватки памяти. Эта ситуация может быть особенно разрушительной, если память выделяется для ввода записи или как-то еще связана с вводом: утечка памяти будет незаметна при использовании незначительных объемов ввода, но внезапно станет очевидной (и приведет в замешательство) при больших. Эта ошибка еще хуже для систем, которые должны работать непрерывно, как в системах телефонных коммутаторов. Утечка памяти, вызывающая крушение такой системы, может привести к значительным денежным или другим потерям.

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

Хотя free() может вернуть освобожденную память системе и сократить адресное пространство процесса, это почти никогда не делается. Вместо этого освобожденная память готова для нового выделения при следующем вызове malloc(), calloc() или realloc().

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

Обсуждение ряда полезных инструментов для отладки динамической памяти см в разделе 15.5.2 «Отладчики выделения памяти».

3.2.1.4. Изменение размера: realloc()

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

Вдобавок, можно изменять размер динамически выделенной области памяти. Хотя можно сократить размер блока памяти, обычно его увеличивают. Изменение размера осуществляется с помощью realloc(). Продолжая пример с coordinates, типичный код выглядит следующим образом:

int new_count;

size_t new_amount;

struct coord *newcoords; /* установить, например: */

new_count = count * 2; /* удвоить размер памяти */

new_amount = new_count * sizeof(struct coord);

newcoords =

 (struct coord*)realloc(coordinates, new_amount);

if (newcoords == NULL) {

 /* сообщить об ошибке, восстановить или прервать */

}

coordinates = newcoords;

/* продолжить использование coordinates ... */

Как и в случае с malloc(), шаги стереотипны по природе и сходны по идее.

1. Вычислить новый выделяемый размер в байтах.

2. Вызвать realloc() с оригинальным указателем, полученным от malloc() (или от calloc() или предыдущего вызова realloc()) и с новым размером.

3. Привести тип и присвоить возвращенное realloc() значение. Подробнее обсудим дальше.

4. Как и для malloc(), проверить возвращенное значение, чтобы убедиться, что оно не равно NULL. Вызов любой функции выделения памяти может завершиться неудачей.

При увеличении размера блока памяти realloc() часто выделяет новый блок нужного размера, копирует данные из старого блока в новый и возвращает указатель уже на новый блок. При сокращении размера блока данных realloc() часто обновляет внутреннюю учетную информацию и возвращает тот же указатель. Это избавляет от необходимости копировать первоначальные данные. Однако, если это случится, не думайте, что можно использовать память за пределами нового размера!

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

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

coordinates = realloc(coordinates, new_amount);

Это плохо по следующей причине. Когда realloc() возвращает NULL, первоначальный указатель все еще действителен; можно безопасно продолжить использовать эту память. Но если вы повторно используете ту же самую переменную и realloc() возвращает NULL, вы теряете указатель на первоначальную память. Эту память больше нельзя использовать. Что еще важнее, эту память невозможно освободить! Это создает утечку памяти, которую нужно избежать.

Для версии realloc() в стандартном С есть некоторые особые случаи: когда аргумент ptr равен NULL, realloc() действует подобно malloc() и выделяет свежий блок памяти. Когда аргумент size равен 0, realloc() действует подобно free() и освобождает память, на которую указывает ptr. Поскольку (а) это может сбивать с толку и (б) более старые системы не реализуют эту возможность, мы рекомендуем использовать malloc(), когда вы имеете в виду malloc(), и free(), когда вы имеете в виду free().

Вот другой довольно тонкий момент[42]. Рассмотрим процедуру, которая содержит статический указатель на динамически выделяемые данные, которые время от времени должны расти. Процедура может содержать также автоматические (т.е. локальные) указатели на эти данные. (Для краткости, мы опустим проверки ошибок. В коде продукта не делайте этого.) Например:

void manage_table(void) {

 static struct table *table;

 struct table *cur, *p;

 int i;

 size_t count;

 ...

 table =

  (struct table*)malloc(count * sizeof(struct table));

 /* заполнить таблицу */

 cur = &table[i]; /* указатель на 1-й элемент */

 ...

 cur->i = j; /* использование указателя */

 ...

 if (/* некоторое условие */) {

  /* нужно увеличить таблицу */

  count += count/2;

  p =

  (struct table*)realloc(table, count * sizeof(struct table));

  table = p;

 }

 cur->i = j; /* ПРОБЛЕМА 1: обновление элемента таблицы */

 other_routine(); /* ПРОБЛЕМА 2: см. текст */

 cur->j = k; /* ПРОБЛЕМА 2: см. текст */

 ...

}

Это выглядит просто; manage_table() размешает данные, использует их, изменяет размер и т.д. Но есть кое-какие проблемы, которые не выходят за рамки страницы (или экрана), когда вы смотрите на этот код.

В строке, помеченной 'ПРОБЛЕМА 1', указатель cur используется для обновления элемента таблицы. Однако, cur был инициализирован начальным значением table. Если некоторое условие верно и realloc() вернула другой блок памяти, cur теперь указывает на первоначальный, освобожденный участок памяти! Каждый раз, когда table меняется, нужно обновить также все указатели на этот участок памяти. Здесь после вызова realloc() и переназначения table недостает строки 'cur = &table[i];'.

Две строки, помеченные 'ПРОБЛЕМА 2', еще более тонкие. В частности, предположим, что other_routine() делает рекурсивный вызов manage_table(). Переменная table снова может быть изменена совершенно незаметно! После возвращения из other_routine() значение cur может снова стать недействительным.

Можно подумать (что мы вначале и сделали), что единственным решением является знать это и добавить после вызова функции переназначение cur с соответствующим комментарием. Однако, Брайан Керниган (Brian Kernighan) любезно нас поправил. Если мы используем индексирование, проблема поддержки указателя даже не возникает:

table =

 (struct table*)malloc(count * sizeof(struct table));

...

/* заполнить таблицу */

...

table[i].i = j; /* Обновить член i-го элемента */

...

if (/* некоторое условие */) {

 /* нужно увеличить таблицу */

 count += count/2;

 p =

  (struct table*)realloc(table, count * sizeof(struct table));

 table = p;

}

table[i].i = j; /* ПРОБЛЕМА 1 устраняется */

other_routine();

/* Рекурсивный вызов, модифицирует таблицу */

table[i].j = k; /* ПРОБЛЕМА 2 также устраняется */

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

ЗАМЕЧАНИЕ. Как и в случае с malloc(), когда вы увеличиваете размер памяти, вновь выделенная после realloc() память не инициализируется нулями. Вы сами при необходимости должны очистить память с помощью memset(), поскольку realloc() лишь выделяет новую память и больше ничего не делает.

3.2.1.5. Выделение с инициализацией нулями: calloc()

Функция calloc() является простой оболочкой вокруг malloc(). Главным ее преимуществом является то, что она обнуляет динамически выделенную память. Она также вычисляет за вас размер памяти, принимая в качестве параметра число элементов и размер каждого элемента:

coordinates = (struct coord*)calloc(count, sizeof(struct coord));

По крайней мере идейно, код calloc() довольно простой. Вот одна из возможных реализаций:

void *calloc(size_t nmemb, size_t size) {

 void *p;

 size_t total;

 total = nmemb * size;   /* Вычислить размер */

 p = malloc(total);      /* Выделить память */

 if (p != NULL)          /* Если это сработало - */

 memset(p, '\0', total); /* Заполнить ее нулями */

 return p; /* Возвращаемое значение NULL или указатель */

}

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

Если вы знаете, что вам понадобится инициализированная нулями память, следует также использовать calloc(), поскольку возможно, что память, возвращенная malloc(), уже заполнена нулями. Хотя вы, программист, не можете этого знать, calloc() может это знать и избежать лишнего вызова memset().

3.2.1.6. Подведение итогов из GNU Coding Standards

Чтобы подвести итоги, процитируем, что говорит об использовании процедур выделения памяти GNU Coding Standards:

Проверяйте каждый вызов malloc или realloc на предмет возвращенного нуля. Проверяйте realloc даже в том случае, если вы уменьшаете размер блока; в системе, которая округляет размеры блока до степени двойки, realloc может получить другой блок, если вы запрашиваете меньше памяти.

В Unix realloc может разрушить блок памяти, если она возвращает ноль. GNU realloc не содержит подобной ошибки: если она завершается неудачей, исходный блок остается без изменений. Считайте, что ошибка устранена. Если вы хотите запустить свою программу на Unix и хотите избежать потерь в этом случае, вы можете использовать GNU malloc.

Вы должны считать, что free изменяет содержимое освобожденного блока. Все, что вы хотите получить из блока, вы должны получать до вызова free.

В этих трех коротких абзацах Ричард Столмен (Richard Stallman) выразил суть важных принципов управления динамической памятью с помощью malloc(). Именно использование динамической памяти и принцип «никаких произвольных ограничений» делают программы GNU такими устойчивыми и более работоспособными по сравнению с их Unix-двойниками.

Мы хотим подчеркнуть, что стандарт С требует, чтобы realloc() не разрушал оригинальный блок памяти, если она возвращает NULL.

3.2.1.7. Использование персональных программ распределения

Набор функций с malloc() является набором общего назначения по выделению памяти. Он должен быть способен обработать запросы на произвольно большие или маленькие размеры памяти и осуществлять все необходимые учетные действия при освобождении различных участков выделенной памяти. Если ваша программа выделяет значительную динамическую память, вы можете обнаружить, что она тратит большую часть своего времени в функциях malloc().

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

Например, GNU awk (gawk) использует эту методику. Выдержка из файла awk.h в дистрибутиве gawk (слегка отредактировано, чтобы уместилось на странице):

#define getnode(n) if (nextfree) n = nextfree, \

 nextfree = nextfree->nextp; else n = more_nodes()

#define freenode(n) ((n)->flags = 0, (n)->exec_count = 0,\

 (n)->nextp = nextfree, nextfree = (n))

Переменная nextfree указывает на связанный список структур NODE. Макрос getnode() убирает из списка первую структуру, если она там есть. В противном случае она вызывает more_nodes(), чтобы выделить новый список свободных структур NODE. Макрос freenode() освобождает структуру NODE, помещая его в начало списка.

ЗАМЕЧАНИЕ. Первоначально при написании своего приложения делайте это простым способом: непосредственно используйте malloc() и free(). Написание собственного распределителя вы должны рассмотреть лишь в том и только в том случае, если профилирование вашей программы покажет, что она значительную часть времени проводит в функциях выделения памяти.

3.2.1.8. Пример: чтение строк произвольной длины

Поскольку это, в конце концов, Программирование на Linux в примерах, настало время для примера из реальной жизни. Следующий код является функцией readline() из GNU Make 3.80 (ftp://ftp.gnu.org/gnu/make/make-3.80.tar.gz). Ее можно найти в файле read.c.

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

Вторичной задачей является распоряжение продлением строк. Как и в С, строки, заканчивающиеся обратным слешем, логически продолжаются со следующей строки. Используется стратегия поддержания буфера. В нем хранится столько строк, сколько помещается в буфер, причем указатели отслеживают начало буфера, текущую строку и следующую строку. Вот структура:

struct ebuffer {

 char *buffer;      /* Начало текущей строки в буфере. */

 char *bufnext;     /* Начало следующей строки в буфере. */

 char *bufstart;    /* Начало всего буфера. */

 unsigned int size; /* Размер буфера для malloc. */

 FILE *fp;          /* Файл или NULL, если это внутренний буфер. */

 struct floc floc;  /* Информация о файле в fp (если он есть). */

};

Поле size отслеживает размер всего буфера, a fp является указателем типа FILE для файла ввода. Структура floc не представляет интереса при изучении процедуры.

Функция возвращает число строк в буфере. (Номера строк здесь даны относительно начала функции, а не исходного файла.)

1  static long

2  readline(ebuf) /* static long readline(struct ebuffer *ebuf) */

3  struct ebuffer *ebuf;

4  {

5   char *p;

6   char *end;

7   char *start;

8   long nlines = 0;

9

10  /* Использование строковых буферов и буферов потоков достаточно

11     различается, чтобы использовать разные функции. */

12

13  if (!ebuf->fp)

14   return readstring(ebuf);

15

16  /* При чтении из файла для каждой новой строки мы всегда

17     начинаем с начала буфера. */

18

19  p = start = ebuf->bufstart;

20  end = p + ebuf->size;

21  *p = '\0';

Для начала заметим, что GNU Make написан на С K&R для максимальной переносимости. В исходной части объявляются переменные, и если ввод осуществляется из строки (как в случае расширения макроса), код вызывает другую функцию, readstring() (строки 13 и 14). Строка '!ebuf->fp' (строка 13) является более короткой (и менее понятной, по нашему мнению) проверкой на пустой указатель; это то же самое, что и 'ebuf->fp==NULL'.

Строки 19-21 инициализируют указатели и вводят байт NUL, который является символом завершения строки С в конце буфера. Затем функция входит в цикл (строки 23–95), который продолжается до завершения всего ввода.

23 while (fgets(p, end - р, ebuf->fp) != 0)

24 {

25  char *p2;

26  unsigned long len;

27  int backslash;

28

29  len = strlen(p);

30  if (len == 0)

31  {

32   /* Это случается лишь тогда, когда первый символ строки '\0'.

33     Это довольно безнадежный случай, но (верите или нет) ляп Афины

34      бьет снова! (xmkmf помещает NUL в свои makefile.)

35      Здесь на самом деле нечего делать; мы создаем новую строку, чтобы

36      следующая строка не была частью данной строки. */

37   error (&ebuf->floc,

38    _("warning: NUL character seen; rest of line ignored"));

39   p[0] = '\n';

40   len = l;

41  }

Функция fgets() (строка 23) принимает указатель на буфер, количество байтов для прочтения и переменную FILE* для файла, из которого осуществляется чтение. Она читает на один байт меньше указанного, чтобы можно было завершить буфер символом '\0'. Эта функция подходит, поскольку она позволяет избежать переполнения буфера. Она прекращает чтение, когда встречается с символами конца строки или конца файла; если это символ новой строки, он помещается в буфер. Функция возвращает NULL при неудаче или значение указателя первого аргумента при успешном завершении.

В этом случае аргументами являются указатель на свободную область буфера, размер оставшейся части буфера и указатель FILE для чтения.

Комментарии в строках 32–36 очевидны; если встречается нулевой байт, программа выводит сообщение об ошибке и представляет вывод как пустую строку. После компенсирования нулевого байта (строки 30–41) код продолжает работу.

43 /* Обойти только что прочитанный текст. */

44 p += len;

45

46 /* Если последний символ - не конец строки, она не поместилась

47    целиком в буфер. Увеличить буфер и попытаться снова. */

48 if (p[-1] != '\n')

49  goto more_buffer;

50

51 /* Мы получили новую строку, увеличить число строк. */

52 ++nlines;

Строки 43–52 увеличивают указатель на участок буфера за только что прочитанными данными. Затем код проверяет, является ли последний прочитанный символ символом конца строки. Конструкция p[-1] (строка 48) проверяет символ перед p, также как p[0] является текущим символом, а p[1] — следующим. Сначала это кажется странным, но если вы переведете это на язык математики указателей, *(p-1), это приобретет больший смысл, а индексированная форма, возможно, проще для чтения.

Если последний символ не был символом конца строки, это означает, что нам не хватило места, и код выходит (с помощью goto) для увеличения размера буфера (строка 49). В противном случае увеличивается число строк.

54 #if !defined(WINDOWS32) && !defined(__MSDOS__)

55 /* Проверить, что строка завершилась CRLF; если так,

56    игнорировать CR. */

57 if ((p - start) > 1 && p[-2] == '\r')

58 {

59  --p;

60  p[-1] = '\n';

61 }

62 #endif

Строки 54–62 обрабатывают вводимые строки, следующие соглашению Microsoft по завершению строк комбинацией символов возврата каретки и перевода строки (CR-LF), а не просто символом перевода строки (новой строки), который является соглашением Linux/Unix. Обратите внимание, что #ifdef исключает этот код на платформе Microsoft, очевидно, библиотека <stdio.h> на этих системах автоматически осуществляет это преобразование. Это верно также для других не-Unix систем, поддерживающих стандартный С.

64  backslash = 0;

65  for (p2 = p - 2; p2 >= start; --p2)

66  {

67   if (*p2 != '\\')

68   break;

69   backslash = !backslash;

70  }

71

72  if (!backslash)

73  {

74   p[-1] = '\0';

75   break;

76  }

77

78  /* Это была комбинация обратный слеш/новая строка. Если есть

79     место, прочесть еще одну строку. */

80  if (end - p >= 80)

81   continue;

82

83  /* В конце буфера нужно больше места, поэтому выделить еще.

84     Позаботиться о сохранении текущего смещения в p. */

85 more_buffer:

86  {

87   unsigned long off = p - start;

88   ebuf->size *= 2;

89   start = ebuf->buffer=ebuf->bufstart=(char*)xrealloc(start,

90    ebuf->size);

91   p = start + off;

92   end = start + ebuf->size;

93   *p = '\0';

94  }

95 }

До сих пор мы имели дело с механизмом получения в буфер по крайней мере одной полной строки. Следующий участок обрабатывает случай строки с продолжением. Хотя он должен гарантировать, что конечный символ обратного слеша не является частью нескольких обратных слешей в конце строки. Код проверяет, является ли общее число таких символов четным или нечетным путем простого переключения переменной backslash из 0 в 1 и обратно. (Строки 64–70.)

Если число четное, условие '!backshlash' (строка 72) будет истинным. В этом случае конечный символ конца строки замещается байтом NUL, и код выходит из цикла.

С другой стороны, если число нечетно, строка содержит четное число пар обратных слешей (представляющих символы \\, как в С), и конечную комбинацию символов обратного слеша и конца строки.[43] В этом случае, если в буфере остались по крайней мере 80 свободных байтов, программа продолжает чтение в цикле следующей строки (строки 78–81). (Использование магического числа 80 не очень здорово; было бы лучше определить и использовать макроподстановку.)

По достижении строки 83 программе нужно больше места в буфере. Именно здесь вступает в игру динамическое управление памятью. Обратите внимание на комментарий относительно сохранения значения p (строки 83-84); мы обсуждали это ранее в терминах повторной инициализации указателей для динамической памяти. Значение end также устанавливается повторно. Строка 89 изменяет размер памяти.

Обратите внимание, что здесь вызывается функция xrealloc(). Многие программы GNU используют вместо malloc() и realloc() функции-оболочки, которые автоматически выводят сообщение об ошибке и завершают программу, когда стандартные процедуры возвращают NULL. Такая функция-оболочка может выглядеть таким образом:

extern const char *myname; /* установлено в main() */


void *xrealloc(void *ptr, size_t amount) {

 void *p = realloc(ptr, amount);

 if (p == NULL) {

  fprintf(stderr, "%s: out of memory!\n", myname);

  exit(1);

 }

 return p;

}

Таким образом, если функция xrealloc() возвращается, она гарантированно возвращает действительный указатель. (Эта стратегия соответствует принципу «проверки каждого вызова на ошибки», избегая в то же время беспорядка в коде, который происходит при таких проверках с непосредственным использованием стандартных процедур.) Вдобавок, это позволяет эффективно использовать конструкцию 'ptr = xrealloc(ptr, new_size)', против которой мы предостерегали ранее.

Обратите внимание, что не всегда подходит использование такой оболочки. Если вы сами хотите обработать ошибки, не следует использовать оболочку. С другой стороны, если нехватка памяти всегда является фатальной ошибкой, такая оболочка вполне удобна.

97   if (ferror(ebuf->fp))

98    pfatal_with_name(ebuf->floc.filenm);

99

100  /* Если обнаружено несколько строк, возвратить их число.

101     Если не несколько, но _что-то_ нашли, значит, прочитана

102     последняя строка файла без завершающего символа конца

103     строки; вернуть 1. Если ничего не прочитано, это EOF;

104     возвратить -1. */

105  return nlines ? nlines : p == ebuf->bufstart ? -1 : 1;

106 }

В заключение, функция readline() проверяет ошибки ввода/вывода, а затем возвращает описательное значение. Функция pfatal_with_name() (строка 98) не возвращается.[44]

3.2.1.9. Только GLIBC: чтение целых строк: getline() и getdelim()

Теперь, когда вы увидели, как читать строки произвольной длины, вы можете сделать вздох облегчения, что вам не нужно самим писать такую функцию. GLIBC предоставляет вам для этого две функции:

#define _GNU_SOURCE 1 /* GLIBC */

#include <stdio.h>

#include <sys/types.h> /* для ssize_t */


ssize_t getline(char **lineptr, size_t *n, FILE *stream);

ssize_t getdelim(char **lineptr, size_t *n, int delim, FILE *stream);

Определение константы _GNU_SOURCE вводит объявления функций getline() и getdelim(). В противном случае они неявно объявлены как возвращающие int. Для объявления возвращаемого типа ssize_t нужен файл <sys/types.h>. (ssize_t является «знаковым size_t». Он предназначен для такого же использования, что и size_t, но в местах, где может понадобиться использование также и отрицательных значений.)

Обе функции управляют для вас динамической памятью, гарантируя, что буфер, содержащий входную строку, достаточно большой для размещения всей строки. Их отличие друг от друга в том, что getline() читает до символа конца строки, a getdelim() использует в качестве разделителя символ, предоставленный пользователем. Общие аргументы следующие:

char **lineptr

Указатель на char* указатель для адреса динамически выделенного буфера. Чтобы getline() сделала всю работу, он должен быть инициализирован NULL. В противном случае, он должен указывать на область памяти, выделенную с помощью malloc().

size_t *n

Указатель на размер буфера. Если вы выделяете свой собственный буфер, *n должно содержать размер буфера. Обе функции обновляют *n новым значением размера буфера, если они его изменяют.

FILE* stream

Место, откуда следует получать входные символы.

По достижении конца файла или при ошибке функция возвращает -1. Строки содержат завершающий символ конца строки или разделитель (если он есть), а также завершающий нулевой байт. Использование getline() просто, как показано в ch03-getline.с:

/* ch03-getline.c --- демонстрация getline(). */

#define _GNU_SOURCE 1

#include <stdio.h>

#include <sys/types.h>


/* main - прочесть строку и отобразить ее, пока не достигнут EOF */

int main(void) {

 char *line = NULL;

 size_t size = 0;

 ssize_t ret;

 while ((ret = getline(&line, &size, stdin)) != -1)

  printf("(%lu) %s", size, line);

 return 0;

}

Вот эта функция в действии, показывающая размер буфера. Третья входная и выходная строки намеренно длинные, чтобы заставить getline() увеличить размер буфера:

$ ch03-getline /* Запустить программу */

this is a line

(120) this is a line

And another line.

(120) And another line.

A llllllllllllllllloooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnngnnnggggggggggg llliiiiiiiiiiiiiiiiiiinnnnnnnnnnnnnnnnnnnneeeeeeeeee

(240) A llllllllllllllllloooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnngnnnggggggggggg llliiiiiiiiiiiiiiiiiiinnnnnnnnnnnnnnnnnnnneeeeeeeeee

3.2.2. Копирование строк: strdup()

Одной чрезвычайно типичной операцией является выделение памяти для копирования строки. Это настолько типично, что многие программисты предусматривают для нее простую функцию вместо использования внутритекстового кодирования, и часто эта функция называется strdup():

#include <string.h>


/* strdup --- выделить память с malloc() и скопировать строку */

char *strdup(const char *str) {

 size_t len;

 char *copy;

 len = strlen(str) + 1;

 /* включить место для завершающего '\0' */

 copy = malloc(len);

 if (copy != NULL) strcpy(copy, str);

 return copy; /* при ошибке возвращает NULL */

}

С появлением стандарта POSIX 2001 программисты по всему миру могут вздохнуть свободнее: эта функция является теперь частью POSIX в виде расширения XSI:

#include <string.h> /* XSI */


char *strdup(const char *str); /* Копировать str */

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

3.2.3. Системные вызовы: brk() и sbrk()

Четыре функции, которые мы рассмотрели (malloc(), calloc(), realloc() и free()) являются стандартными, переносимыми функциями для управления динамической памятью.

На Unix-системах стандартные функции реализованы поверх двух дополнительных, очень примитивных процедур, которые непосредственно изменяют размер адресного пространства процесса. Мы представляем их здесь, чтобы помочь вам понять, как работают GNU/Linux и Unix (снова «под капотом»); крайне маловероятно, что вам когда-нибудь понадобится использовать эти функции в обычных программах. Они определены следующим образом:

#include <unistd.h> /* Обычный */

#include <malloc.h> /* Необходим для систем GLIBC 2 */


int brk(void *end_data_segment);

void *sbrk(ptrdiff_t increment);

Системный вызов brk() действительно изменяет адресное пространство процесса. Адрес является указателем, представляющим окончание сегмента данных (на самом деле, области кучи, как было показано ранее на рис. 3.1). Ее аргумент является абсолютным логическим адресом, представляющим новое окончание адресного пространства. В случае успеха функция возвращает 0, а в случае неуспеха (-1).

Функцию sbrk() использовать проще; ее аргумент является числом байтов, на которое нужно увеличить адресное пространство. Вызвав ее с приращением 0, можно определить, где в настоящее время заканчивается адресное пространство. Таким образом, чтобы увеличить адресное пространство на 32 байта, используется код следующего вида:

char *p = (char*)sbrk(0); /* получить текущий конец адресного

                             пространства */

if (brk(p + 32) < 0) {

 /* обработать ошибку */

}

/* в противном случае, изменение сработало */

Практически, вам не нужно непосредственно использовать brk(). Вместо этого используется исключительно sbrk() для увеличения (или даже сокращения) адресного пространства. (Вскоре мы покажем, как это делать, в разделе 3.2.5. «Исследование адресного пространства».)

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

Но знать о низкоуровневых механизмах стоит, и конечно же, набор функций malloc() реализован с помощью sbrk() и brk().

3.2.4. Вызовы ленивых программистов: alloca()

«Опасность, Билл Робинсон! Опасность!»

- Робот -
Есть еще одна дополнительная функция выделения памяти, о которой вам нужно знать. Мы обсуждаем ее лишь для того, чтобы вы поняли ее, когда увидите, но не следует использовать ее в новых программах! Эта функция называется alloca(); она объявлена следующим образом:

/* Заголовок в GNU/Linux, возможно, не на всех Unix-системах */

#include <alloca.h> /* Обычный */


void *alloca(size_t size);

Функция alloca() выделяет size байтов из стека. Хорошо, что выделенная память исчезает после возвращения из функции. Нет необходимости явным образом освобождать память, поскольку это осуществляется автоматически, как в случае с локальными переменными.

На первый взгляд, alloca() выглядит чем-то типа панацеи для программистов, можно выделять память, о которой можно вовсе не беспокоиться. Подобно Темной Стороне Силы, это, конечно, привлекает. И подобным же образом этого нужно избегать по следующим причинам:

• Функция не является стандартной; она не включена ни в какой стандарт, ни в ISO, ни в С или POSIX.

• Функция не переносима. Хотя она существует на многих системах Unix и GNU/Linux, она не существует на не-Unix системах. Это проблема, поскольку код часто должен быть многоплатформенным, выходя за пределы просто Linux и Unix.

• На некоторых системах alloca() невозможно даже реализовать. Весь мир не является ни процессором Intel x86, ни GCC.

• Цитируя справку[45] (добавлено выделение): «Функция alloca зависит от машины и от компилятора. На многих системах ее реализация ошибочна. Ее использование не рекомендуется».

• Снова цитируя справку: «На многих системах alloca не может быть использована внутри списка аргументов вызова функции, поскольку резервируемая в стеке при помощи alloca память оказалась бы в середине стека в пространстве для аргументов функции».

• Она потворствует неряшливому программированию. Тщательная и корректная работа с памятью не сложна; вам просто нужно подумать о том, что вы делаете, и планировать заранее.

GCC обычно использует встроенную версию функции, которая действует с использованием внутритекстового (inline) кода. В результате есть другие последствия alloca(). Снова цитируя справку:

Факт, что код является внутритекстовым (inline), означает, что невозможно получить адрес этой функции или изменить ее поведение путем компоновки с другой библиотекой.

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

Справочная страница не углубляется в описание проблемы со встроенной alloca() GCC. Если есть переполнение стека, возвращаемое значение является мусором. И у вас нет способа сообщить об этом! Это упущение делает невозможным использование GCC alloca() в устойчивом коде.

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

3.2.5. Исследование адресного пространства

Следующая программа, ch03-memaddr.c, подводит итог всему, что мы узнали об адресном пространстве. Она делает множество вещей, которые не следует делать на практике, таких, как вызовы alloca() или непосредственные вызовы brk() и sbrk().

1  /*

2   * ch03-memaddr.с --- Показать адреса секций кода, данных и стека,

3   * а также BSS и динамической памяти.

4   */

5

6  #include <stdio.h>

7  #include <malloc.h> /* для определения ptrdiff_t в GLIBC */

8  #include <unistd.h>

9  #include <alloca.h> /* лишь для демонстрации */

10

11 extern void afunc(void); /* функция, показывающая рост стека */

12

13 int bss_var; /* автоматически инициализируется в 0, должна быть в BSS */

14 int data_var = 42; /* инициализируется в не 0, должна быть

15                       в сегменте данных */

16 int

17 main(int argc, char **argv) /* аргументы не используются */

18 {

19  char *p, *b, *nb;

20

21  printf("Text Locations:\n");

22  printf("\tAddress of main: %p\n", main);

23  printf("\tAddress of afunc: %p\n", afunc);

24

25  printf("Stack Locations.\n");

26  afunc();

27

28  p = (char*)alloca(32);

29  if (p != NULL) {

30   printf("\tStart of alloca()'ed array: %p\n", p);

31   printf("\tEnd of alloca()'ed array: %p\n", p + 31);

32  }

33

34  printf("Data Locations:\n");

35  printf("\tAddress of data_var: %p\n", &data_var);

36

37  printf("BSS Locations:\n");

38  printf("\tAddress of bss_var: %p\n", &bss_var);

39

40  b = sbrk((ptrdiff_t)32); /* увеличить адресное пространство */

41  nb = sbrk((ptrdiff_t)0);

42  printf("Heap Locations:\n");

43  printf("\tInitial end of heap: %p\n", b);

44  printf("\tNew end of heap: %p\n", nb);

45

46  b = sbrk((ptrdiff_t)-16); /* сократить его */

47  nb = sbrk((ptrdiff_t)0);

48  printf("\tFinal end of heap: %p\n", nb);

49 }

50

51 void

52 afunc(void)

53 {

54  static int level = 0; /* уровень рекурсии */

55  auto int stack_var; /* автоматическая переменная в стеке */

56

57  if (++level == 3) /* избежать бесконечной рекурсии */

58   return;

59

60  printf("\tStack level %d: address of stack_var: %p\n",

61   level, &stack_var);

62  afunc(); /* рекурсивный вызов */

63 }

Эта программа распечатывает местонахождение двух функций main() и afunc() (строки 22–23). Затем она показывает, как стек растет вниз, позволяя afunc() (строки 51–63) распечатать адреса последовательных экземпляров ее локальной переменной stack_var. (stack_var намеренно объявлена как auto, чтобы подчеркнуть, что она находится в стеке.) Затем она показывает расположение памяти, выделенной с помощью alloca() (строки 28–32). В заключение она печатает местоположение переменных данных и BSS (строки 34–38), а затем памяти, выделенной непосредственно через sbrk() (строки 40–48). Вот результаты запуска программы на системе Intel GNU/Linux:

$ ch03-memaddr

Text Locations:

 Address of main: 0x804838c

 Address of afunc: 0x80484a8

Stack Locations:

 Stack level 1: address of stack_var: 0xbffff864

 Stack level 2: address of stack_var: 0xbffff844

  /* Стек растет вниз */

 Start of alloca()'ed array: 0xbffff860

 End of alloca()'ed array: 0xbffff87f

  /* Адреса находятся в стеке */

Data Locations:

 Address of data_var: 0x80496b8

BSS Locations:

 Address of bss_var: 0x80497c4

  /* BSS выше инициализированных данных */

Heap Locations:

 Initial end of heap: 0x80497c8

  /* Куча непосредственно над BSS */

 New end of heap: 0x80497e8

  /* И растет вверх */

 Final end of heap: 0x80497d8

  /* Адресные пространства можно сокращать */

3.3. Резюме

• У каждой программы Linux и (Unix) есть различные области памяти. Они хранятся в разных частях файла исполняемой программы на диске. Некоторые из секций загружаются при запуске программы в одну и ту же область памяти. Все запушенные экземпляры одной и той же программы разделяют исполняемый код (сегмент текста). Программа size показывает размеры различных областей переместимых объектных файлов и полностью скомпонованных исполняемых файлов.

• В адресном пространстве запушенной программы могут быть дыры, а размер адресного пространства может изменяться при выделении и освобождении памяти. На современных системах адрес 0 не является частью адресного пространства, поэтому не пытайтесь разыменовывать указатели NULL.

• На уровне языка С память выделяется с помощью одной из функций malloc(), calloc() или realloc(). Память освобождается с помощью free(). (Хотя с помощью realloc() можно делать все, использование ее таким образом не рекомендуется.) Освобожденная память обычно не удаляется из адресного пространства; вместо этого она используется повторно при последующих выделениях.

• Необходимо предпринять чрезвычайные меры осторожности в следующих случаях

 • освобождать лишь память, выделенную с помощью соответствующих процедур,

 • освобождать память один и только один раз,

 • освобождать неиспользуемую память и

 • не допускать «утечки» динамически выделяемой памяти.

• POSIX предоставляет для удобства функцию strdup(), a GLIBC предоставляет функции getline() и getdelim() для чтения строк произвольной длины. Функции интерфейса низкоуровневых системных вызовов brk() и sbrk() предоставляют непосредственный, но примитивный доступ к выделению и освобождению памяти. Если вы не создаете свой собственный распределитель памяти, следует избегать их. Существует функция alloca() для выделения памяти в стеке, но ее использование не рекомендуется. Подобно умению распознавать ядовитый плющ, про нее нужно знать лишь для того, чтобы избегать ее.

Упражнения

1. Начав со структуры —

struct line {

 size_t buflen;

 char *buf;

 FILE* fp;

};

— напишите свою собственную функцию readline(), которая будет читать строки любой длины. Не беспокойтесь о строках, продолженных с помощью обратного слеша. Вместо использования fgetc() для чтения строк используйте getc() для чтения одного символа за раз.

2. Сохраняет ли ваша функция завершающий символ конца строки? Объясните, почему.

3. Как ваша функция обрабатывает строки, оканчивающиеся CR-LF?

4. Как вы инициализируете структуру? В отдельной процедуре? С помощью документированных условий для определенных значений в структуре?

5. Как вы обозначаете конец файла? Как вы указываете, что возникла ошибка ввода/вывода? Должна ли ваша функция сообщать об ошибках? Объясните, почему.

6. Напишите программу, которая использует вашу функцию для ее тестирования, а также другую программу, создающую входные данные для первой программы. Протестируйте функцию.

7. Перепишите вашу функцию с использованием fgets() и протестируйте ее. Является ли новый код более сложным или менее сложным? Какова его производительность по сравнению с версией getc()?

8. Изучите страницу справки V7 для end(3) (/usr/man/man3/end.3 в дистрибутиве V7). Пролила ли она свет на то, как может работать 'sbrk(0)'?

9. Усовершенствуйте ch03-memaddr.c так, чтобы она печатала расположение аргументов и переменных окружения. В какой области адресного пространства они находятся?

Глава 4 Файлы и файловый ввод/вывод

Данная глава описывает базовые файловые операции: открытие и создание файлов, чтение и запись в них, перемещение в них и их закрытие. По ходу дела она представляет стандартные механизмы для обнаружения ошибок и сообщений о них. Глава заканчивается описанием того, как установить длину файла и принудительно сбросить данные файла и вспомогательные данные на диск.

4.1. Введение в модель ввода/вывода Linux/Unix

Модель API Linux/Unix для ввода/вывода проста. Ее можно суммировать четырьмя словами. открыть, прочитать, записать, закрыть. Фактически, это имена системных вызовов: open(), read(), write(), close(). Вот их объявления:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h> /* для mode_t */

#include <fcntl.h>    /* для flags для open() */

#include <unistd.h>   /* для ssize_t */


int open(const char *pathname, int flags, mode_t mode);

ssize_t read(int fd, void *buf, size_t count);

ssize_t write(int fd, const void *buf, size_t count);

int close(int fd);

В следующем и дальнейших разделах мы проиллюстрируем модель, написав очень простую версию cat. Она так проста, что даже не имеет опций; все, что она делает, — объединяет содержимое двух именованных файлов и выводит его в стандартный вывод. Она выводит минимум сообщений об ошибках. Написав, мы сравним ее с V7 cat.

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

4.2. Представление базовой структуры программы

Наша версия cat следует структуре, которая обычно является полезной. Первая часть начинается с комментариев, заголовочных файлов, объявлений и функции main():

1  /*

2   * ch04-cat.c --- Демонстрация open(), read(), write(), close(),

3   * errno и strerror().

4   */

5

6  #include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

7  #include <errno.h> /* объявление errno */

8  #include <fcntl.h> /* для flags для open() */

9  #include <string.h> /* объявление strerror() */

10 #include <unistd.h> /* для ssize_t */

11 #include <sys/types.h>

12 #include <sys/stat.h> /* для mode_t */

13

14 char *myname;

15 int process(char *file);

16

17 /* main --- перечислить аргументы файла */

18

19 int

20 main(int argc, char **argv)

21 {

22  int i;

23  int errs = 0;

24

25  myname = argv[0];

26

27  if (argc == 1)

28   errs = process("-");

29  else

30   for (i = 1; i < argc; i++)

31  errs += process(argv[i]);

32

33  return (errs != 0);

34 }

…продолжение далее в главе.

Переменная myname (строка 14) используется далее для сообщений об ошибках; main() первым делом устанавливает в ней имя программы (argv[0]). Затем main() в цикле перечисляет аргументы. Для каждого аргумента она вызывает функцию process().

Когда в качестве имени файла дано - (простая черточка, или знак минус), cat Unix вместо попытки открыть файл с именем читает стандартный ввод. Вдобавок, cat читает стандартный ввод, когда нет аргументов. ch04-cat реализует оба этих поведения. Условие 'argc == 1' (строка 27) истинно, когда нет аргументов имени файла; в этом случае main() передает «-» функции process(). В противном случае, main() перечисляет аргументы, рассматривая их как файлы, которые необходимо обработать. Если один из них окажется «-», программа обрабатывает стандартный ввод.

Если process() возвращает ненулевое значение, это означает, что случилась какая- то ошибка. Ошибки подсчитываются в переменной errs (строки 28 и 31). Когда main() завершается, она возвращает 0, если не было ошибок, и 1, если были (строка 33). Это довольно стандартное соглашение, значение которого более подробно обсуждается в разделе 9.1.5.1 «Определение статуса завершения процесса».

Структура, представленная в main(), довольно общая: process() может делать с файлом все, что мы захотим. Например (игнорируя особый случай «-»), process() также легко могла бы удалять файлы вместо их объединения!

Прежде чем рассмотреть функцию process(), нам нужно описать, как представлены ошибки системных вызовов и как осуществляется ввод/вывод. Сама функция process() представлена в разделе 4.4.3 «Чтение и запись».

4.3. Определение ошибок

«Если неприятность может произойти, она случается»

- Закон Мерфи -
«Будь готов»

- Бойскауты -
Ошибки могут возникнуть в любое время. Диски могут заполниться, пользователи могут ввести неверные данные, сетевой сервер, с которого осуществляется чтение, может отказать, сеть может выйти из строя и т.д. Важно всегда проверять успешность завершения каждой операции.

Основные системные вызовы Linux почти всегда возвращают при ошибке -1 и 0 или положительное значение при успехе. Это дает возможность узнать, была операция успешной или нет:

int result;

result = some_system_call(param1, param2);

if (result < 0) {

 /* ошибка, что-нибудь сделать */

} else

 /* все нормально, продолжить */

Знания того, что произошла ошибка, недостаточно. Нужно знать, какая произошла ошибка. Для этого у каждого процесса есть предопределенная переменная с именем errno. Всякий раз, когда системный вызов завершается ошибкой, errno устанавливается в один из набора предопределенных значений ошибок errno и предопределенные значения ошибок определены в файле заголовка <errno.h>.

#include <errno.h> /* ISO С */


extern int errno;

Хотя сама errno может быть макросом, который действует подобно переменной int — она не обязательно является действительной целой переменной. В частности, в многопоточном окружении у каждого потока будет своя индивидуальная версия errno. Несмотря на это, практически для всех системных вызовов и функций в данной книге вы можете рассматривать errno как простую int.

4.3.1. Значения errno

Стандарт POSIX 2001 определяет большое число возможных значений для errno. Многие из них относятся к сетям, IPC или другим специальным задачам. Справочная страница для каждого системного вызова описывает возможные значения errno, которые могут иметь место; поэтому вы можете написать код для проверки отдельных ошибок и соответствующим образом обработать их, если это нужно. Возможные значения определены через символические имена. Предусмотренные GLIBC значения перечислены в табл. 4.1.


Таблица 4.1. Значения GLIBC для errno

Имя Значение
E2BIG Слишком длинный список аргументов
EACCESS Доступ запрещен
EADDRINUSE Адрес используется
EADDRNOTAVAIL Адрес недоступен
EAFNOSUPPORT Семейство адресов не поддерживается
EAGAIN Ресурс недоступен, попытайтесь снова (может быть то же самое значение, что EWOULDBLOCK).
EALREADY Соединение уже устанавливается
EBADF Ошибочный дескриптор файла.
EBADMSG Ошибочное сообщение.
EBUSY Устройство или ресурс заняты
ECANCELED Отмена операции.
ECHILD Нет порожденного процесса.
ECONNABORTED Соединение прервано
ECONNFRFUSED Соединение отклонено
ECONNRESET Восстановлено исходное состояние соединения.
EDEADLK Возможен тупик (deadlock) в запросе ресурса.
EDESTADDRREQ Требуется адрес назначения
EDOM Математический аргумент выходит за область определения функции
EDQUOT Зарезервировано.
EEXIST Файл существует.
EFAULT Ошибочный адрес.
EFBIG Файл слишком большой.
EHOSTUNREACH Хост недоступен.
EIDRM Идентификатор удален
EILSEQ Ошибочная последовательность байтов.
EINPROGRESS Операция исполняется.
EINTR Прерванная функция.
EINVAL Недействительный аргумент.
EIO Ошибка ввода/вывода.
EISCONN Сокет (уже) соединен.
EISDIR Это каталог.
ELOOP Слишком много уровней символических ссылок.
EMFILE Слишком много открытых файлов.
EMLINK Слишком много ссылок.
EMSGSIZE Сообщение слишком длинное.
EMULTIHOP Зарезервировано.
ENAMETOOLONG Имя файла слишком длинное
ENETDOWN Сеть не работает
ENETRESET Соединение прервано сетью
ENETUNREACH Сеть недоступна.
ENFILE В системе открыто слишком много файлов.
ENOBUFS Буферное пространство недоступно.
ENODEV Устройство отсутствует
ENOENT Файл или каталог отсутствуют
ENOEXEC Ошибочный формат исполняемого файла.
ENOLCK Блокировка недоступна.
ENOLINK Зарезервировано.
ENOMEM Недостаточно памяти.
ENOMSG Сообщение нужного типа отсутствует
ENOPROTOOPT Протокол недоступен.
ENOSPC Недостаточно памяти в устройстве.
ENOSYS Функция не поддерживается.
ENOTCONN Сокет не соединен.
ENOTDIR Это не каталог
ENOTEMPTY Каталог не пустой.
ENOTSOCK Это не сокет
ENOTSUP Не поддерживается
ENOTTY Неподходящая операция управления вводом/выводом
ENXIO Нет такого устройства или адреса.
EOPNOTSUPP Операция сокета не поддерживается
EOVERFLOW Слишком большое значение для типа данных
EPERM Операция не разрешена
EPIPE Канал (pipe) разрушен
EPROTO Ошибка протокола.
EPROTONOSUPPORT Протокол не поддерживается
EPROTOTYPE Ошибочный тип протокола для сокета
ERANGE Результат слишком большой
EROFS Файловая система только для чтения
ESPIPE Недействительный поиск
ESRCH Нет такого процесса
ESTALE Зарезервировано
ETIMEDOUT Тайм-аут соединения истек
ETXTBSY Текстовый файл занят
EWOULDBLOCK Блокирующая операция (может быть то же значение, что и для EAGAIN)
EXDEV Ссылка через устройство (cross-device link)
Многие системы предоставляют также другие значения ошибок, а в более старых системах может не быть всех перечисленных значений ошибок. Полный список следует проверить с помощью справочных страниц intro(2) и errno(2) для локальной системы.

ЗАМЕЧАНИЕ. errno следует проверять лишь после того, как возникла ошибка и до того, как сделаны дальнейшие системные вызовы. Начальное значение той переменной 0. Однако, в промежутках между ошибками ничто не изменяет ее значения, это означает, что успешный системный вызов не восстанавливает значение 0. Конечно, вы можете вручную установить ее в 0 в самом начале или когда захотите, однако это делается редко.

Сначала мы используем errno лишь для сообщений об ошибках. Для этого имеются две полезные функции. Первая — perror():

#include <stdio.h> /* ISO С */


void perror(const char *s);

Функция perror() выводит предоставленную программой строку, за которой следует двоеточие, а затем строка, описывающая значение errno:

if (some_system_call(param1, param2) < 0) {

 perror("system call failed");

 return 1;

}

Мы предпочитаем функцию strerror(), которая принимаетпараметр со значением ошибки и возвращает указатель на строку с описанием ошибки:

#include <string.h> /* ISO С */


char *strerror(int errnum);

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

if (some_system_call(param1, param2) < 0) {

 fprintf(stderr, "%s: %d, %d: some_system_call failed: %s\n",

  argv[0], param1, param2, strerror(errno));

 return 1;

}

По всей книге вы увидите множество примеров использования обеих функций.

4.3.2. Стиль сообщения об ошибках

Для использования в сообщениях об ошибках С предоставляет несколько специальных макросов. Наиболее широкоупотребительными являются __FILE__ и __LINE__, которые разворачиваются в имя исходного файла и номер текущей строки в этом файле. В С они были доступны с самого начала. C99 определяет дополнительный предопределенный идентификатор, __func__, который представляет имя текущей функции в виде символьной строки. Макросы используются следующим образом:

if (some_system_call(param1, param2) < 0) {

 fprintf(stderr, "%s: %s (%s %d): some_system_call(%d, %d) failed: %s\n",

  argv[0], __func__, __FILE__, __LINE__,

  param1, param2, strerror(errno));

 return 1;

}

Здесь сообщение об ошибке включает не только имя программы, но также и имя функции, имя исходного файла и номер строки. Полный список идентификаторов, полезных для диагностики, приведен в табл. 4.2.


Таблица 4.2. Диагностические идентификаторы C99

Идентификатор Версия С Значение
__DATE__ C89 Дата компиляции в виде «Mmm nn yyyy»
__FILE_ Оригинальная Имя исходного файла в виде «program.c»
__LINE__ Оригинальная Номер строки исходного файла в виде 42
__TIME__ C89 Время компиляции в виде «hh:mm:ss»
__func__ C99 Имя текущей функции, как если бы было объявлено const char __func__[] = "name"
Использование __FILE__ и __LINE__ было вполне обычно для ранних дней Unix, когда у большинства людей были исходные коды и они могли находить ошибки и устранять их. По мере того, как системы Unix становились все более коммерческими, использование этих идентификаторов постепенно уменьшалось, поскольку знание положения в исходном коде дает немного пользы, когда имеется лишь двоичный исполняемый файл.

Сегодня, хотя системы GNU/Linux поставляются с исходными кодами, указанный исходный код часто не устанавливается по умолчанию. Поэтому использование этих идентификаторов для сообщений об ошибках не представляет дополнительной ценности. GNU Coding Standards даже не упоминает их.

4.4. Ввод и вывод

Все операции Linux по вводу/выводу осуществляются посредством дескрипторов файлов. Данный раздел знакомит с дескрипторами файлов, описывает, как их получать и освобождать, и объясняет, как выполнять с их помощью ввод/вывод.

4.4.1. Понятие о дескрипторах файлов

Дескриптор файла является целым значением. Действительные дескрипторы файлов начинаются с 0 и растут до некоторого установленного системой предела. Эти целые фактически являются индексами таблицы открытых файлов для каждого процесса (Таблица поддерживается внутри операционной системы; она недоступна запущенным программам.) В большинстве современных систем размеры таблиц большие. Команда 'ulimit -n' печатает это значение:

$ ulimit -n

1024

Из С максимальное число открытых файлов возвращается функцией getdtablesize() (получить размер таблицы дескрипторов):

#include <unistd.h> /* Обычный */


int getdtablesize(void);

Следующая небольшая программа выводит результат работы этой функции:

/* ch04-maxfds.с --- Демонстрация getdtablesize(). */

#include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

#include <unistd.h> /* для ssize_t */


int main(int argc, char **argv) {

 printf("max fds: %d\n", getdtablesize());

 exit(0);

}

Неудивительно, что после компиляции и запуска эта программа выводит то же значение, что и ulimit:

$ ch04-maxfds

max fds: 1024

Дескрипторы файлов содержатся в обычных переменных int; для использования с системными вызовами ввода/вывода можно увидеть типичные объявления вида 'int fd'. Для дескрипторов файлов нет предопределенного типа.

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

Очевидные символические константы. Оксюморон?
При работе с системными вызовами на основе дескрипторов файлов и стандартных ввода, вывода и ошибки целые константы 0, 1 и 2 обычно используются прямо в коде. В подавляющем большинстве случаев использование таких символических констант (manifest constants) является плохой мыслью. Вы никогда не знаете, каково значение некоторой случайной целой константы и имеет ли к ней какое-нибудь отношение константа с тем же значением, использованная в другой части кода. С этой целью стандарт POSIX требует объявить следующие именованные константы (symbolic constants) в <unistd.h>:

STDIN_FILENO  «Номер файла» для стандартного ввода: 0.

STDOUT_FILENO Номер файла для стандартного вывода: 1.

STDERR_FILENO Номер файла для стандартной ошибки: 2.

Однако, по нашему скромному мнению, использование этих макросов избыточно. Во-первых, неприятно набирать 12 или 13 символов вместо 1. Во-вторых, использование 0, 1 и 2 так стандартно и так хорошо известно, что на самом деле нет никаких оснований для путаницы в смысле этих конкретных символических констант.

С другой стороны, использование этих констант не оставляет сомнений в намерениях программиста. Сравните это утверждение:

int fd = 0;

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

Один из подходов (рекомендованный Джеффом Колье (Geoff Collyer)) заключается в использовании следующего определения enum:

enum { Stdin, Stdout, Stderr };

Затем эти константы можно использовать вместо 0, 1 и 2. Их легко читать и печатать.

4.4.2. Открытие и закрытие файлов

Новые дескрипторы файлов получают (наряду с другими источниками) в результате системного вызова open(). Этот системный вызов открывает файл для чтения или записи и возвращает новый дескриптор файла для последующих операций с этим файлом. Мы видели объявление раньше:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>


int open(const char *pathname, int flags, mode_t mode);

Три аргумента следующие:

const char *pathname

Строка С, представляющая имя открываемого файла.

int flags

Поразрядное ИЛИ с одной или более констант, определенных в <fcntl.h>. Вскоре мы их рассмотрим.

mode_t mode

Режимы доступа для создаваемого файла. Это обсуждается далее в главе, см. раздел 4.6 «Создание файлов». При открытии существующего файла опустите этот параметр[46].

Возвращаемое open() значение является либо новым дескриптором файла, либо -1, означающим ошибку, в этом случае будет установлена errno. Для простого ввода/вывода аргумент flags должен быть одним из значений из табл. 4.3.


Таблица 4.3. Значения flags для open()

Именованная константа Значение Комментарий
O_RDONLY 0 Открыть файл только для чтения, запись невозможны
O_WRONLY 1 Открыть файл только для записи, чтение невозможно
O_RDWR 2 Открыть файл для чтения и записи
Вскоре мы увидим пример кода. Дополнительные значения flags описаны в разделе 4.6 «Создание файлов». Большой объем ранее написанного кода Unix не использовал эти символические значения. Вместо этого использовались числовые значения. Сегодня это рассматривается как плохая практика, но мы представляем эти значения, чтобы вы их распознали, если встретитесь с ними

Системный вызов close() закрывает файл: его элемент в системной таблице дескрипторов файлов помечается как неиспользуемый, и с этим дескриптором нельзя производить никаких дальнейших действий. Объявление следующее:

#include <unistd.h> /* POSIX */


int close(int fd);

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

Если вы будете игнорировать возвращаемое значение, специально приведите его к типу void, чтобы указать, что вам не нужен результат:

(void)close(fd); /* отказ от возвращаемого значения */

Легкомысленность этого совета в том, что слишком большое количество приведений к void имеют тенденцию загромождать код. Например, несмотря на принцип «всегда проверять возвращаемое значение», чрезвычайно редко можно увидеть код, проверяющий возвращаемое значение printf() или приводящий его к void. Как и со многими аспектами программирования на С, здесь также требуются опыт и рассудительность.

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

Система закрывает все открытые файлы, когда процесс завершается, но — за исключением 0, 1 и 2 — плохая манера полагаться на это.

Когда open() возвращает новый дескриптор файла, она всегда возвращает наименьшее неиспользуемое целое значение. Всегда. Поэтому, если открыты дескрипторы файлов 0–6 и программа закрывает дескриптор файла 5, следующий вызов open() вернет 5, а не 7. Это поведение важно; далее в книге мы увидим, как оно используется для аккуратной реализации многих важных особенностей Unix, таких, как перенаправление ввода/вывода и конвейеризация (piping)

4.4.2.1. Отображение переменных FILE* на дескрипторы файлов

Стандартные библиотечные функции ввода/вывода и переменные FILE* из <stdio.h>, такие, как stdin, stdout и stderr, построены поверх основанных на дескрипторах файлов системных вызовах.

Иногда полезно получить непосредственный доступ к дескриптору файла, связанному с указателем файла <stdio.h>, если вам нужно сделать что-либо, не определенное стандартом С ISO. Функция fileno() возвращает лежащий в основе дескриптор файла:

#include <stdio.h> /* POSIX */


int fileno(FILE *stream);

Пример мы увидим позже, в разделе 4.4.4. «Пример: Unix cat».

4.4.2.2. Закрытие всех открытых файлов

Открытые файлы наследуются порожденными процессами от своих родительских процессов. Фактически они являются общими. В частности, общим является положение в файле. Подробности мы оставим для дальнейшего обсуждения в разделе 9.1.1.2 «Разделение дескрипторов файлов».

Поскольку программы могут наследовать другие файлы, иногда вы можете увидеть программы, которые закрывают все свои файлы, чтобы начать с «чистого состояния» В частности, типичен код наподобие этого:

int i;

/* оставить лишь 0, 1, и 2 */

for (i = 3; i < getdtablesize(); i++)

 (void)close(i);

Предположим, что результат getdtablesize() равен 1024. Этот код работает, но он делает (1024-3)*2 = 2042 системных вызова. 1020 из них не нужны, поскольку возвращаемое значение getdtablesize() не изменяется. Вот лучший вариант этого кода:

int i, fds;

for (i = 3, fds = getdtablesize(); i < fds; i++)

 (void)close(i);

Такая оптимизация не ухудшает читаемость кода, но может быть заметна разница, особенно на медленных системах. В общем, стоит поискать случаи, когда в циклах повторно вычисляется один и тот же результат, чтобы посмотреть, нельзя ли вынести вычисление за пределы цикла. Хотя в таких случаях нужно убедиться, что вы (а) сохраняете правильность кода и (б) сохраняете его читаемость!

4.4.3. Чтение и запись

Ввод/вывод осуществляется системными вызовами read() и write() соответственно:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>


ssize_t read(int fd, void *buf, size_t count);

ssize_t write(int fd, const void *buf, size_t count);

Каждая функция сделана как можно проще. Аргументами являются дескриптор открытого файла, указатель на буфер для чтения или записи данных и число читаемых или записываемых байтов.

Возвращаемое значение является числом действительно прочитанных или записанных байтов. (Это число может быть меньше запрошенного: при операции чтения это происходит, когда в файле осталось меньше count байтов, а при операции записи это случается, когда диск заполнен или произошла еще какая-нибудь ошибка.) Возвращаемое значение -1 означает возникшую ошибку, в этом случае errno указывает эту ошибку. Когда read() возвращает 0, это означает, что достигнут конец файла.

Теперь мы можем показать оставшуюся часть кода для ch04-cat. Процедура process() использует 0 для стандартного ввода, если именем файла является «-» (строки 50 и 51). В противном случае она открывает данный файл:

36 /*

37   * process --- сделать что-то с файлом, в данном случае,

38   * послать его в stdout (fd 1).

39   * Возвращает 0, если все нормально; в противном случае 1.

40   */

41

42 int

43 process(char *file)

44 {

45  int fd;

46  ssize_t rcount, wcount;

47  char buffer[BUFSIZ];

48  int errors = 0;

49

50  if (strcmp(file, "-") == 0)

51   fd = 0;

52  else if ((fd = open(file, O_RDONLY)) < 0) {

53   fprintf(stderr, "%s: %s: cannot open for reading: %s\n",

54    myname, file, strerror(errno));

55   return 1;

56  }

Буфер buffer (строка 47) имеет размер BUFSIZ; эта константа определена В <stdio.h> как «оптимальный» размер блока для ввода/вывода. Хотя значение BUFSIZ различается в разных системах, код, использующий эту константу, чистый и переносимый.

Основой процедуры является следующий цикл, который повторно читает данные до тех пор, пока не будет достигнут конец файла или не возникнет ошибка.

58 while ((rcount = read(fd, buffer, sizeof buffer)) > 0) {

59  wcount = write(1, buffer, rcount);

60  if (wcount != rcount) {

61   fprintf(stderr, "%s: %s: write error: %s\n",

62    myname, file, strerror(errno));

63   errors++;

64   break;

65  }

66 }

Переменные rcount и wcount (строка 45) имеют тип ssize_t, «знаковый size_t», который позволяет хранить в них отрицательные значения. Обратите внимание, что число байтов, переданное write(), является значением, возвращенным read() (строка 59). Хотя мы хотим читать порциями фиксированного размера в BUFSIZ, маловероятно, что размер самого файла кратен BUFSIZ. При чтении из файла завершающей, меньшей порции байтов, возвращаемое значение указывает, сколько байтов buffer получили новые данные. В стандартный вывод должны быть скопированы только эти байты, а не весь буфер целиком.

Условие 'wcount != rcount' в строке 60 является правильным способом проверки на ошибки; если были записаны некоторые, но не все данные, wcount будет больше нуля, но меньше rcount.

В заключение process() проверяет наличие ошибок чтения (строки 68–72), а затем пытается закрыть файл. В случае (маловероятном) неудачного завершения close() (строка 75) она выводит сообщение об ошибке. Избежание закрытия стандартного ввода не является абсолютно необходимым в данной программе, но является хорошей привычкой при разработке больших программ, в случае, когда другой код где-то в другом месте хочет что-то с ним делать или если порожденная программа будет наследовать его. Последний оператор (строка 82) возвращает 1, если были ошибки, и 0 в противном случае.

68  if (rcount < 0) {

69   fprintf(stderr, "%s: %s: read error: %s\n",

70    myname, file, strerror(errno));

71   errors++;

72  }

73

74  if (fd != 0) {

75   if (close(fd) < 0) {

76    fprintf(stderr, "%s: %s: close error: %s\n",

77     myname, file, strerror(errno));

78    errors++;

79   }

80  }

81

82  return (errors != 0);

83 }

ch04-cat проверяет на ошибки каждый системный вызов. Хотя это утомительно, зато предоставляет устойчивость (или по крайней мере, ясность): когда что-то идет не так, ch04-cat выводит сообщение об ошибке, которое специфично настолько, насколько это возможно. В сочетании с errno и strerror() это просто. Вот все с ch04-cat, всего 88 строк кода!

Для подведения итогов вот несколько важных моментов, которые нужно понять относительно ввода/вывода в Unix:

Ввод/вывод не интерпретируется

Системные вызовы ввода/вывода просто перемешают байты. Они не интерпретируют данные; вся интерпретация оставлена программе уровня пользователя. Это делает чтение и запись двоичных структур таким же простым, как чтение и запись строк текста (на самом деле, проще, хотя использование двоичных данных привносит проблемы переносимости).

Ввод/вывод гибок

За один раз вы можете прочесть или записать столько байтов, сколько захотите. Вы можете даже читать или записывать данные по одному байту за раз, хотя для больших объемов данных это обходится дороже, чем использование больших порций.

Ввод/вывод прост

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

Ввод/вывод может быть частичным

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

4.4.4. Пример: Unix cat

Как и было обещано, вот версия cat V7[47]. Она начинается с проверки опций, cat V7 принимает единственную опцию, -u, для осуществления небуферированного вывода.

Общая структура сходна с той, которую мы видели ранее; программа перечисляет файлы, указанные в аргументах командной строки и читает каждый файл, по одному символу за раз, посылая этот символ в стандартный вывод. В отличие от нашей версии, она использует возможности <stdio.h>. Во многих случаях код, использующий стандартную библиотеку ввода/вывода, проще читать и писать, поскольку все проблемы с буферами скрыты библиотекой.

1  /*

2   * Объединение файлов.

3   */

4

5  #include <stdio.h>

6  #include <sys/types.h>

7  #include <sys/stat.h>

8

9  char stdbuf[BUFSIZ];

10

11 main(argc, argv) /* int main(int argc, char **argv) */

12 char **argv;

13 {

14  int fflg = 0;

15  register FILE *fi;

16  register c;

17  int dev, ino = -1;

18  struct stat statb;

19

20  setbuf(stdout, stdbuf);

21  for( ; argc>1 && argv[1][0] == '-'; argc--, argv++) {

22   switch(argv[1][1]) { /* Обработка опций */

23   case 0:

24    break;

25   case 'u':

26    setbuf(stdout, (char*)NULL);

27    continue;

28   }

29   break;

30  }

31  fstat(fileno(stdout), &statb); /* Строки 31-36 объясняются в главе 5 */

32  statb.st_mode &= S_IFMT;

33  if (statb.st_mode != S_IFCHR && statb.st_mode != S_IPBLK) {

34   dev = statb.st_dev;

35   ino = statb.st_ino;

36  }

37  if (argc < 2) {

38   argc = 2;

39   fflg++;

40  }

41  while (--argc > 0) { // Loop over files

42   if (fflg || (*++argv)[0] == '-' && (*argv)[1] == '\0')

43    fi = stdin;

44   else {

45    if ((fi = fopen(*argv, "r")) == NULL) {

46     fprintf(stderr, "cat: can't open %s\n", *argv);

47    continue;

48   }

49  }

50  fstat(fileno(fi), &statb); /* Строки 50-56 объясняются в главе 5 */

51  if (statb.st_dev == dev && statb.st_ino == ino) {

52   fprintf(stderr, "cat: input %s is output\n",

53    fflg ? "-" : *argv);

54   fclose(fi);

55   continue;

56  }

57  while ((c=getc(fi)) != EOF) /* Копировать содержимое в stdout */

58   putchar(с);

59  if (fi != stdin)

60   fclose(fi);

61  }

62  return(0);

63 }

Следует заметить, что программа всегда завершается успешно (строка 62); можно было написать ее так, чтобы отмечать ошибки и указывать их в возвращаемом значении main(). (Механизм завершения процесса и значение различных кодов завершения обсуждаются в разделе 9.1.5.1 «Определение статуса завершения процесса».)

Код, работающий с struct stat и функцией fstat() (строки 31–36 и 50–56), без сомнения, непрозрачен, поскольку мы еще не рассматривали эти функции и не будем рассматривать до следующей главы (Но обратите внимание на использование fileno() в строке 50 для получения нижележащего дескриптора файла, связанного с переменными FILE*.) Идея в основе этого кода заключается в том, чтобы убедиться, что входной и выходной файлы не совпадают. Это предназначено для предотвращения бесконечного роста файла, в случае подобной команды:

$ cat myfile >> myfile /* Добавить копию myfile к себе? */

И конечно же, проверка работает:

$ echo hi > myfile /* Создать файл */

$ v7cat myfile >> myfile /* Попытка добавить файл к себе */

cat: input myfile is output

Если вы попробуете это с ch04-cat, программа продолжит работу, и myfile будет расти до тех пор, пока вы не прервете ее. GNU версия cat осуществляет эту проверку. Обратите внимание, что что-то вроде этого выходит за рамки контроля cat:

$ v7cat < myfile > myfile

cat: input - is output

$ ls -l myfile

-rw-r--r-- 1 arnold devel 0 Mar 24 14:17 myfile

В данном случае это слишком поздно, поскольку оболочка урезала файл myfile (посредством оператора >) еще до того, как cat получила возможность исследовать файл! В разделе 5.4.4.2 «Возвращаясь к V7 cat» мы объясним код с struct stat.

4.5. Произвольный доступ: перемещения внутри файла

До сих пор мы обсуждали последовательный ввод/вывод, при котором данные читаются или записываются с начала файла и продолжаются до его конца. Часто это все, что требуется программе. Однако, возможно осуществление произвольного ввода/вывода; т.е. читать данные из произвольного положения в файле без необходимости предварительного чтения всего, что находится перед этим местом.

Смещение дескриптора файла является положением внутри открытого файла, начиная с которого будет осуществляться следующая операция чтения или записи. Программа устанавливает смещение с помощью системного вызова lseek():

#include <sys/types.h> /* для off_t; POSIX */

#include <unistd.h> /* объявления lseek() и значений whence */


off_t lseek(int fd, off_t offset, int whence);

Тип off_t (тип смещения) является знаковым целым, представляющим позиции байтов (смещений от начала) внутри файла. На 32-разрядных системах тип представлен обычно как long. Однако, многие современные системы допускают очень большие файлы, в этом случае off_t может быть более необычным типом, таким, как C99 int64_t или какой-нибудь другой расширенный тип. lseek() принимает три следующих аргумента.

int fd

Дескриптор открытого файла.

off_t offset

Позиция, в которую нужно переместиться. Интерпретация этого значения зависит от параметра whence. offset может быть положительным или отрицательным; отрицательные значения перемещают к началу файла; положительные значения перемещают к концу файла.

int whence

Описывает положение в файле, относительно которого отсчитывается offset. См. табл. 4.4.


Таблица 4.4. Значения whence для lseek()

Именованная константа Значение Комментарий
SEEK_SET 0 offset абсолютно, т.е. относительно начала файла
SEEK_CUR 1 offset относительно текущей позиции в файле
SEEK_END 2 offset относительно конца файла.
Большое количество старого кода использует числовые значения, приведенные в табл. 4.4. Однако, любой новый код, который вы пишете, должен использовать символические имена, значение которых более ясно.

Смысл значений и их действие на положение в файле показаны на рис. 4.1. При условии, что файл содержит 3000 байтов и что перед каждым вызовом lseek() текущим является смещение 2000 байтов, новое положение после каждого вызова будет следующим.

Рис. 4.1. Смещения для lseek()

Отрицательные смещения относительно начала файла бессмысленны; они вызывают ошибку «недействительный параметр».

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

off_t curpos;

...

curpos = lseek(fd, (off_t)0, SEEK_CUR);

Буква l в lseek() означает long. lseek() был введен в V7 Unix, когда размеры файлов были увеличены; в V6 был простой системный вызов seek(). В результате большое количество старой документации (и кода) рассматривает параметр offset как имеющий тип long, и вместо приведения к типу off_t довольно часто можно видеть суффикс L в константных значениях смешений:

curpos = lseek(fd, 0L, SEEK_CUR);

На системах с компилятором стандартного С, где lseek() объявлена с прототипом, такой старый код продолжает работать, поскольку компилятор автоматически преобразует 0L из long в off_t, если это различные типы.

Одной интересной и важной особенностью lseek() является то, что она способна устанавливать смещение за концом файла. Любые данные, которые впоследствии записываются в это место, попадают в файл, но с образованием «интервала» или «дыры» между концом предыдущих данных файла и началом новых данных. Данные в промежутке читаются, как если бы они содержали все нули.

Следующая программа демонстрирует создание дыр. Она записывает три экземпляра struct в начало, середину и дальний конец файла. Выбранные смешения (строки 16–18, третий элемент каждой структуры) произвольны, но достаточно большие для демонстрации особенности:

1  /* ch04-holes.c --- Демонстрация lseek() и дыр в файлах. */

2

3  #include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

4  #include <errno.h> /* объявление errno */

5  #include <fcntl.h> /* для flags для open() */

6  #include <string.h> /* объявление strerror() */

7  #include <unistd.h> /* для ssize_t */

8  #include <sys/types.h> /* для off_t, etc. */

9  #include <sys/stat.h>  /* для mode_t */

10

11 struct person {

12  char name[10]; /* имя */

13  char id[10]; /* идентификатор */

14  off_t pos; /* положение в файле для демонстрации */

15 } people[] = {

16  { "arnold", "123456789", 0 },

17  { "miriam", "987654321", 10240 },

18  { "joe", "192837465", 81920 },

19 };

20

21 int

22 main(int argc, char **argv)

23 {

24  int fd;

25  int i, j;

26

27  if (argc < 2) {

28   fprintf(stderr, "usage: %s file\n", argv[0]);

29   return 1;

30  }

31

32  fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0666);

33  if (fd < 0) {

34   fprintf(stderr, "%s: %s: cannot open for read/write: %s\n",

35    argv[0], argv[1], strerror(errno));

36   return 1;

37  }

38

39  j = sizeof(people) / sizeof(people[0]); /* число элементов */

Строки 27–30 гарантируют, что программа была вызвана правильно. Строки 32–37 открывают именованный файл и проверяют успешность открытия.

Вычисление числа элементов j массива в строке 39 использует отличный переносимый трюк число элементов является размером всего массива, поделенного на размер первого элемента. Красота этого способа в том, что он всегда верен: неважно, сколько элементов вы добавляете в массив или удаляете из него, компилятор это выяснит. Он не требует также завершающей сигнальной метки; т.е. элемента, в котором все поля содержат нули, NULL или т.п.

Работа осуществляется в цикле (строки 41–55), который отыскивает смещение байтов, приведенное в каждой структуре (строка 42), а затем записывает всю структуру (строка 49):

41  for (i = 0; i < j; i++) {

42   if (lseek(fd, people[i].pos, SEEK_SET) < 0) {

43    fprintf(stderr, "%s: %s: seek error: %s\n",

44     argv[0], argv[1], strerror(errno));

45    (void)close(fd);

46    return 1;

47   }

48

49   if (write(fd, &people[i], sizeof(people[i])) != sizeof(people[i])) {

50    fprintf(stderr, "%s: %s: write error: %s\n",

51     argv[0], argv[1], strerror(errno));

52    (void)close(fd);

53    return 1;

54   }

55  }

56

57  /* здесь все нормально */

58  (void)close(fd);

59  return 0;

60 }

Вот результаты запуска программы:

$ ch04-holes peoplelist /* Запустить программу */

$ ls -ls peoplelist /* Показать использованные размеры и блоки */

16 -rw-r--r-- 1 arnold devel 81944 Mar 23 17:43 peoplelist

$ echo 81944 / 4096 | bc -l /* Показать блоки, если нет дыр */

20.00585937500000000000

Случайно мы знаем, что каждый дисковый блок файла использует 4096 байтов. (Откуда мы это знаем, обсуждается в разделе 5 4.2 «Получение информации о файле». Пока примите это как данное.) Финальная команда bc указывает, что файлу размером 81944 байтов нужен 21 дисковый блок. Однако, опция -s команды ls, которая сообщает нам, сколько блоков использует файл на самом деле, показывает, что файл использует лишь 16 блоков![48] Отсутствующие блоки в файле являются дырами. Это показано на рис. 4.2.

Рис. 4.2. Дыры в файле

ЗАМЕЧАНИЕch04-holes.c не осуществляет непосредственный двоичный ввод/вывод. Это хорошо демонстрирует красоту ввода/вывода с произвольным доступом: вы можете рассматривать дисковый файл, как если бы он был очень большим массивом двоичных структур данных.

На практике сохранение данных путем использования двоичного ввода/вывода является решением, которое необходимо тщательно взвесить. Например, что если предположить, что вам нужно переместить данные на систему, использующую отличный порядок байтов для целых? Или другие форматы чисел с плавающей точкой? Или на систему с другими требованиями выравнивания? Игнорирование подобных вопросов может стать слишком дорогостоящим.

4.6. Создание файлов

Как было описано ранее, open(), очевидно, открывает лишь существующие файлы. Данный раздел описывает, как создавать новые файлы. Есть две возможности: creat() и open() с дополнительными файлами. Первоначально creat() был единственным способом создания файла, но затем эта возможность была добавлена также и к open(). Оба механизма требуют указания начальных прав доступа к файлу.

4.6.1. Определение начальных прав доступа к файлу

Как пользователь GNU/Linux, вы знакомы с правами доступа к файлу, выдаваемыми командой 'ls -l': на чтение, запись и исполнение для каждого из владельца файла, группы и остальных. Различные сочетания часто выражаются в восьмеричной форме, в частности, для команд chmod и chmask. Например, права доступа к файлу -rw-r--r-- эквивалентны восьмеричному 0644, a -rwxr-xr-x эквивалентно восьмеричному 0755. (Ведущий 0 в нотации С означает восьмеричные значения.)

Когда вы создаете файл, вы должны знать, какую защиту необходимо назначить новому файлу. Вы можете сделать это с помощью простого восьмеричного числа, если захотите, и такие числа довольно обычно можно увидеть в старом коде. Однако, лучше использовать побитовую операцию OR для одной или более символических имен из <sys/stat.h>, описанных в табл. 4.5.


Таблица 4.5. Символические имена POSIX для режимов доступа к файлу

Символическое имя Значение Комментарий
S_IRWXU 00700 Разрешение на чтение, запись и исполнение для владельца
S_IRUSR 00400 Разрешение на чтение для владельца
S_IREAD Аналогично S_IRUSR
S_IWUSR 00200 Разрешение на запись для владельца
S_IWRITE Аналогично S_IWUSR
S_IXUSR 00100 Разрешение на исполнение для владельца.
S_IEXEC Аналогично S_IXUSR
S_IRWXG 00070 Разрешение на чтение, запись и исполнение для группы
S_IRGRP 00040 Разрешение на чтение для группы
S_IWGRP 00020 Разрешение на запись для группы.
S_IXGRP 00010 Разрешение на исполнение для группы
S_IRWXO 00007 Разрешение на чтение, запись и исполнение для остальных.
S_IROTH 00004 Разрешение на чтение для остальных.
S_IWOTH 00002 Разрешение на запись для остальных
S_IXOTH 00001 Разрешение на исполнение для остальных
Следующий фрагмент показывает, как создать переменные, представляющие разрешения -rw-r--r-- и -rwxr-xr-x (0644 и 0755 соответственно):

mode_t rw_mode, rwx_mode;

rw_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; /* 0644 */

rwx_mode = S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH; /* 0755 */

Более старый код использовал S_IREAD, S_IWRITE и S_IEXEC вместе со сдвигом битов для получения того же результата:

mode_t rw_mode, rwx_mode;

rw_mode = (S_IREAD|S_IWRITE) | (S_IREAD >> 3) | (S_IREAD >> 6); /* 0644 */

rwx_mode = (S_IREAD|S_IWRITE|S_IEXEC) |

 ((S_IREAD|S_IEXEC) >> 3) | ((S_IREAD|S_IEXEC) >> 6); /* 0755 */

К сожалению, ни одна из записей не является очень удобной. Современные версии предпочтительнее, поскольку у каждого бита доступа есть собственное имя и меньше вероятность неправильного выполнения побитовых операций.

При изменении прав доступа к файлу для использования доступны биты дополнительных разрешений, показанные в табл. 4.6, но они не должны использоваться при первоначальном создании файла. Возможность включения этих битов широко варьирует между операционными системами. Лучше всего не пробовать; вместо этого следует изменить права доступа к файлу явным образом после его создания. (Изменение прав доступа описано в разделе 5.5.2 «Изменение прав доступа: chmod() и fchmod()». Значения этих битов обсуждаются в главе 11 «Права доступа и идентификаторы пользователя и группы».)


Таблица 4.6. Дополнительные символические имена POSIX для режимов доступа к файлам

Символическое имя Значение Смысл
S_ISUID 04000 Установить ID пользователя
S_ISGID 02000 Установить ID группы
S_ISVTX 01000 Сохранить текст
Когда стандартные утилиты создают файлы, они по умолчанию используют права доступа -rw-rw-rw- (или 0666). Поскольку большинство пользователей предпочитают избегать файлов, в которые может записывать кто угодно, каждый процесс имеет при себе umask. umask является набором битов допуска, указывающим те биты, которые никогда не должны устанавливаться при создании новых файлов, (umask не используется при изменении прав доступа.) Концептуально осуществляется операция

действительные_права = (затребованные_права & (~umask));

umask обычно устанавливается с помощью команды umask в $НОМЕ/.profile, когда вы входите в систему. Из программы С она устанавливается с помощью системного вызова umask().

#include <sys/types.h> /* POSIX */

#include <sys/stat.h> mode_t umask(mode_t mask);

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

mode_t mask = umask(0); /* получить текущую маску */

(void)umask(mask); /* восстановить ее */

Вот пример работы umask на уровне оболочки:

$ umask /* Показать текущую маску */

0022

$ touch newfile /* Создать файл */

$ ls -l newfile /* Показать права доступа нового файла */

-rw-r--r-- 1 arnold devel 0 Mar 24 15:43 newfile

$ umask 0 /* Установить пустую маску */

$ touch newfile2 /* Создать второй файл */

$ ls -l newfile2 /* Показать права доступа нового файла */

-rw-rw-rw- 1 arnold devel 0 Mar 24 15:44 newfile2

4.6.2. Создание файлов с помощью creat()

Системный вызов creat()[49] создает новые файлы. Он объявлен следующим образом:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>


int creat(const char *pathname, mode_t mode);

Аргумент mode представляет права доступа к новому файлу (как обсуждалось в предыдущем разделе). Создается файл с именем pathname.с данными правами доступа, модифицированными с использованием umask. Он открыт (только) для чтения, а возвращаемое значение является дескриптором нового файла или -1, если была проблема. В последнем случае errno указывает ошибку. Если файл уже существует, он будет при открытии урезан.

Во всех остальных отношениях дескрипторы файлов, возвращаемые creat(), являются теми же самыми, которые возвращаются open(); они используются для записи и позиционирования и должны закрываться при помощи close():

int fd, count;

/* Проверка ошибок для краткости опущена */

fd = creat("/some/new/file", 0666);

count = write(fd, "some data\n", 10);

(void)close(fd);

4.6.3. Возвращаясь к open()

Вы можете вспомнить объявление для open():

int open(const char *pathname, int flags, mode_t mode);

Ранее мы сказали, что при открытии файла для простого ввода/вывода мы можем игнорировать аргумент mode. Хотя, посмотрев на creat(), вы, возможно, догадались, что open() также может использоваться для создания файлов и что в этом случае используется аргумент mode. Это в самом деле так.

Помимо флагов O_RDONLY, O_WRONLY и O_RDWR, при вызове open() могут добавляться с использованием поразрядного OR дополнительные флаги. Стандарт POSIX предоставляет ряд этих дополнительных флагов. В табл. 4.7 представлены флаги, которые используются для большинства обычных приложений.


Таблица 4.7. Дополнительные флаги POSIX для open()

Флаг Значение
O_APPEND Принудительно осуществляет все записи в конец файла
O_CREAT Создает новый файл, если он несуществует.
O_EXCL При использовании вместе с O_CREAT возвращает ошибку, если файл уже существует
O_TRUNC Урезает файл (устанавливает его длину в 0), если он существует.
Если даны O_APPEND и O_TRUNC, можно представить, как оболочка могла бы открывать или создавать файлы, соответствующие операторам > и >>. Например:

int fd;

extern char *filename;

mode_t mode = S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH; /* 0666 */

fd = open(filename, O_CREAT | O_WRONLY | O_TRUNC, mode); /* для > */

fd = open(filename, O_CREAT | O_WRONLY | O_APPEND, mode); /* для >> */

Обратите внимание, что флаг O_EXCL здесь не используется, поскольку как для >, так и для >> не является ошибкой существование файла. Запомните также, что система применяет к запрошенным правам доступа umask.

Также легко видеть, что, по крайней мере концептуально, creat() можно было бы легко написать следующим образом:

int creat(const char *path, mode_t mode) {

 return open(path, O_CREAT | O_WRONLY | O_TRUNC, mode);

}

ЗАМЕЧАНИЕ. Если файл открыт с флагом O_APPEND, все данные будут записаны в конец файла, даже если текущее смещение было восстановлено с помощью lseek().

Современные системы предоставляют дополнительные флаги с более специализированным назначением. Они кратко описаны в табл. 4.8.


Таблица 4.8. Дополнительные расширенные флаги POSIX для open()

Флаг Значение
O_APPEND Принудительно осуществляет все записи в конец файла
O_CREAT Создает новый файл, если он не существует.
O_EXCL При использовании вместе с O_CREAT возвращает ошибку, если файл уже существует
O_TRUNC Урезает файл (устанавливает его длину в 0), если он существует.
Флаги O_DSYNC, O_RSYNC и O_SYNC требуют некоторых пояснений. Системы Unix (включая Linux) содержат внутренний кэш дисковых блоков, который называется буферным кэшем (buffer cache). Когда возвращается системный вызов write(), данные, переданные операционной системе, были скопированы в буфер в буферном кэше. Они необязательно были записаны на диск.

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

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

Все это кэширование, конечно, замечательно, но бесплатного обеда не бывает. В то время, пока данные находятся в буферном кэше и до того, как они будут записаны на диск, есть небольшое, но вполне реальное окно, в котором может случиться катастрофа; например, если выключат питание. Современные дисковые приводы обостряют эту проблему: у многих из них есть собственные внутренние буферы, поэтому при записи данных на диск они могут оказаться не записанными на носитель при выключении питания! Это может быть значительной проблемой для небольших систем, которые не находятся в информационном центре с контролируемым энергоснабжением или не имеют источников бесперебойного питания (UPS).[50]

Для большинства приложений вероятность того, что данные в буферном кэше могут быть нечаянно потеряны, довольно низка. Однако, для некоторых приложений любой такой шанс неприемлем. Поэтому в системе Unix было введено понятие синхронного ввода/вывода, при котором программе гарантируется, что по возвращении из системного вызова данные безопасно записаны на физическое устройство хранения.

Флаг O_DSYNC гарантирует целостность данных; данные и любая другая информация, которую операционная система должна найти, записываются на диск до возвращения write(). Однако, вспомогательные данные, такие, как время модификации или доступа к файлу, могут быть не записаны на диск. Флаг O_SYNC требует, чтобы эти данные также были записаны на диск до возвращения write(). (Здесь тоже нет бесплатного обеда; синхронные записи могут серьезно повлиять на производительность программы, заметно ее снизив.)

Флаг O_RSYNC предназначен для чтения данных: если read() находит данные в буферном кэше, которые были назначены для записи на диск, функция не вернет эти данные до тех пор, пока они не будут записаны. Два других флага влияют на это: в частности, O_SYNC заставит read() ждать, пока не будут также записаны и вспомогательные данные.

ЗАМЕЧАНИЕ. Что касается ядра версии 2.4, Linux рассматривает все три флага одинаково со значением флага O_SYNC. Более того, Linux определяет дополнительные флаги, которые специфичны для Linux и предназначены для специального использования. Дополнительные подробности см. в справочной странице GNU/Linux для open(2).

4.7. Форсирование записи данных на диск

Ранее мы описали флаги O_DSYNC, O_RSYNC и O_SYNC для open(). Мы отметили, что использование этих флагов может замедлить программу, поскольку write() не возвращается до тех пор, пока все данные не будут записаны на физический носитель.

Со слегка более высоким уровнем риска мы можем сами испечь свое пирожное и съесть его. Это осуществляется путем открытия файла без указания флагов O_xSYNC, но с последующим использованием одного из следующих двух системных вызовов в любой момент, когда это необходимо для безопасного перемещения данных на физический носитель:

#include <unistd.h>


int fsync(int fd); /* POSIX FSC */

int fdatasync(int fd); /* POSIX SIO */

Системный вызов fdatasync() подобен O_DSYNC: он форсирует запись данных на конечное физическое устройство. Системный вызов fsync() подобен O_SYNC, форсируя запись на физическое устройство не только данных файла, но и вспомогательных данных. Вызов fsync() более переносим; он существовал в мире Unix в течение более продолжительного времени, и вероятность его наличия среди широкого ряда систем больше.

Можно использовать эти вызовы с указателями файлов <stdio.h>, вызвав сначала fflush(), а затем fileno() для получения дескриптора нижележащего файла. Вот функция fpsync(), которая может использоваться для заключения обеих операций в один вызов. Она возвращает в случае успеха 0:

/* fpsync --- синхронизация переменной stdio FILE* */

int fpsync(FILE *fp) {

 if (fp == NULL || fflush(fp) == EOF || fsync(fileno(fp)) < 0)

  return -1;

 return 0;

}

Технически оба этих вызова являются расширениями базового стандарта POSIX: fsync() в расширении «Синхронизация файлов» (FSC), a fdatasync() в расширении «Синхронизированный ввод и вывод». Тем не менее, можно без проблем использовать их в системе GNU/Linux

4.8. Установка длины файла

Два системных вызова позволяют настраивать размер файла:

#include <unistd.h>

#include <sys/types.h>


int truncate(const char *path, off_t length); /* XSI */

int ftruncate(int fd, off_t length); /* POSIX */

Как должно быть очевидно из параметров, truncate() принимает аргумент имени файла, тогда как ftruncate() работает с дескриптором открытого файла. (Обычным является соглашение по именованию пар системных вызовов xxx() и fxxxx(), работающих с именами файлов и дескрипторами файлов. Мы увидим несколько примеров в данной и последующих главах.) В обоих случаях аргумент length является новым размером файла.

Этот системный вызов происходит от 4.2 BSD Unix, и на ранних системах мог использоваться лишь для сокращения длины файла, отсюда и название. (Он был создан, чтобы облегчить реализацию операции урезания в Фортране.) На современных системах, включая Linux, имя является неправильным, поскольку с помощью этих вызовов можно также увеличить, а не только сократить длину файла. (Однако, POSIX указывает, что возможность увеличения размера файла относится к расширению XSI.)

Для этих вызовов сокращаемый файл должен иметь разрешение на запись (для truncate()), или должен быть открыт для записи (для ftruncate()). Если файл сокращается, все данные после нового конца файла теряются. (Поэтому вы не можете сократить файл, снова удлинить его и найти там первоначальные данные.) Если файл-расширен, как в случае записи данных после lseek(), данные между старым концом файла и новым концом файла читаются как нули.

Эти вызовы сильно отличаются от 'open(file, ... | O_TRUNC, mode)', который полностью урезает файл, отбрасывая все его данные. Эти же вызовы просто устанавливают абсолютную длину файла в данное значение.

Эти функции довольно специализированы; они используются лишь четыре раза во всем коде GNU Coreutils. Мы представляем пример использования ftruncate() в разделе 5.5.3 «Изменение отметок времени: utime()».

4.9. Резюме

• Когда системный вызов завершается неудачей, он обычно возвращает -1, а в глобальной переменной errno устанавливается предопределенное значение, указывающее на проблему. Для сообщений об ошибках могут использоваться функции perror() и strerror().

• Доступ к файлам осуществляется через небольшие целые, которые называются дескрипторами. Дескрипторы файлов для стандартного ввода, стандартного вывода и стандартной ошибки наследуются от родительского процесса программы. Другие получаются через open() или creat(). Для их закрытия используется close(), a getdtablesize() возвращает разрешенное максимальное число открытых файлов. Значение umask (устанавливаемое с помощью umask()) влияет на права доступа, получаемые новыми файлами при создании с помощью creat() или с флагом O_CREAT для open().

• Системные вызовы read() и write() соответственно читают и записывают данные. Их интерфейс прост. В частности, они не интерпретируют данные, файлы представлены линейными потоками байтов. Системный вызов lseek() осуществляет ввод/выводе произвольным доступом: возможность перемещаться внутри файла.

• Для синхронного ввода/вывода предусмотрены дополнительные флаги для open(), при этом данные записываются на физический носитель данных до возвращения write() или read(). Можно также форсировать запись данных на диск на управляемой основе с помощью fsync() или fdatasync().

• Системные вызовы truncate() и ftruncate() устанавливают абсолютную длину файла. (На более старых системах они могут использоваться лишь для сокращения длины файла; на современных системах они могут также увеличивать файл.)

Упражнения

1. Используя лишь open(), read(), write() и close(), напишите простую программу copy, которая копирует файл, имя которого дается в первом аргументе, в файл с именем во втором аргументе.

2. Усовершенствуйте программу copy так, чтобы она принимала "-" в значении «стандартный ввод» при использовании в качестве первого аргумента и в значении «стандартный вывод» в качестве второго аргумента. Правильно ли работает 'copy - -'?

3. Просмотрите страничку справки для proc(5) на системе GNU/Linux. В частности, посмотрите подраздел fd. Выполните 'ls -l /dev/fd' и непосредственно проверьте файлы в /proc/self/fd. Если бы /dev/stdin и дружественные устройства были бы в ранних версиях Unix, как это упростило бы код для программы V7 cat? (Во многих других современных системах Unix есть каталог или файловая система /dev/fd. Если вы не используете GNU/Linux, посмотрите, что вы можете обнаружить в своей версии Unix.)

4. Даже если вы пока этого не понимаете, постарайтесь скопировать сегмент кода из V7 cat.c, который использует struct stat и функцию fstat(), в ch04-cat.c, чтобы она также сообщала об ошибке для 'cat file >> file'.

5. (Простое) Предположив наличие strerror(), напишите свою версию perror().

6. Каков результат выполнения 'ulimit -n' на вашей системе?

7. Напишите простую версию программы umask, назвав ее myumask, которая принимает в командной строке восьмеричную маску. Используйте strtol() с основанием 8 для преобразования строки символов аргумента командной строки в целое значение. Измените umask с помощью системного вызова umask().

Откомпилируйте и запустите myumask, затем проверьте значение umask с помощью стандартной команды umask. Объясните результаты. (Подсказка: в оболочке Bash введите 'type umask'.)

8. Измените простую программу copy, которую вы написали ранее, для использования open() с флагом O_SYNC. Используя команду time, сравните характеристики первоначальной и новой версии большого файла.

9. Мы сказали, что для ftruncate() файл должен быть открыт для записи. Как можно открыть файл для записи, когда у самого файла нет доступа записи?

10. Напишите программу truncate, которая используется следующим образом: 'truncate длина_файла'.

Глава 5 Каталоги и служебные данные файлов

Данная глава продолжает подъем по кривой обучения до следующего плато: понимания каталогов и информации о файлах.

В данной главе мы исследуем то, как информация хранится в каталоге, как читаются, создаются и удаляются сами каталоги, какая информация о файлах доступна и как ее получить. Наконец, мы рассмотрим другие способы обновления служебных данных файлов, таких, как владелец, группа, права доступа и время доступа и изменения файла.

5.1. Просмотр содержимого каталога

Все Unix-системы, включая Linux, используют для хранения файловой информации на диске один и тот же концептуальный дизайн. Хотя в реализации дизайна есть значительные вариации, интерфейс на уровне С остается постоянным, давая возможность писать переносимые программы, которые компилируются и запускаются на многих различных системах.

5.1.1. Определения

Рис. Copyright 1997-2004 © J.D. «Illiad» Frazer. Использовано по разрешению, http://www.userfriendly.org

Мы начнем обсуждение с определения нескольких терминов.

Раздел (partition)

Единица физического хранилища. Физические разделы обычно являются либо частями диска, либо целым диском. Современные системы дают возможность создавать из нескольких физических логические разделы.

Файловая система (filesystem)

Раздел (физический или логический), содержащий данные файла и служебные данные (metadata), информацию о файлах (в противоположность содержимому файла, которое является информацией в файле). Такие служебные данные включают владельца файла, права доступа, размер и т.д., а также информацию, использующуюся операционной системой при поиске содержимого файла. Файловые системы размещаются «в» разделах (соотношение одни к одному) посредством записи в них стандартной информации. Это осуществляется программой уровня пользователя, такой, как mke2fs в GNU/Linux или newfs в Unix. (Команда Unix mkfs создает разделы, но ее трудно использовать, непосредственно, newfs вызывает ее с нужными параметрами. Если ваша система является системой Unix, подробности см. в справочных страницах для newfs(8) и mkfs(8).)

Большей частью GNU/Linux и Unix скрывают наличие файловых систем и разделов. (Дополнительные подробности приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».) Доступ ко всему осуществляется через пути, безотносительно к тому, на каком диске расположен файл. (Сравните это с почти любой коммерческой операционной системой, такой, как OpenVMS, или с поведением по умолчанию любой системы Microsoft.)

Индекс (inode)

Сокращение от 'index node' (индексный узел), первоначально сокращалось 'i-node', а теперь пишется 'inode'. Небольшой блок информации, содержащий все сведения о файле, за исключением имени файла. Число индексов и, следовательно, число уникальных файлов в файловой системе, устанавливается и делается постоянным при создании файловой системы. Команда 'df -i' может показать, сколько имеется индексов и сколько из них используется.

Устройство (device)

В контексте файлов, файловых систем и служебных данных файлов, уникальный номер, представляющий используемую («смонтированную») файловую систему. Пара (устройство, индекс) однозначно идентифицирует файл: два различных файла будут гарантированно иметь различные пары (устройство, индекс). Более подробно это обсуждается далее в этой главе.

Каталог (directory)

Специальный файл, содержащий список пар (индекс, имя). Каталоги могут быть открыты для чтения, но не для записи; все изменения в содержимом каталога делает операционная система.

Концептуально каждый дисковый блок содержит либо некоторое число индексов, либо данные файла. Индекс, в свою очередь, содержит указатели на блоки, содержащие данные файла. См. рис. 5.1.

Рис. 5.1. Концептуальное представление индексов и блоков данных

На рисунке показаны все блоки индексов перед разделом и блоки данных после них. Ранние файловые системы Unix были организованы именно таким способом. Однако, хотя все современные системы до сих пор содержат индексы и блоки данных, их организация для повышения эффективности и устойчивости была изменена. Детали меняются от системы к системе, и даже в рамках систем GNU/Linux имеется множество разновидностей файловых систем, но концепция остается той же самой.

5.1.2. Содержимое каталога

Каталоги устанавливают связь между именем файла и индексом. Элементы каталога содержат номер индекса и имя файла. Они содержат также дополнительную учетную информацию, которая нам здесь не интересна. См. рис. 5.2.

Рис. 5.2. Концептуальное содержание каталога

На ранних Unix-системах были двухбайтные номера индексов, а имена файлов — до 14 байтов. Вот полное содержание файла V7 /usr/include/sys/dir.h:

#ifndef DIRSIZ

#define DIRSIZ 14

#endif


struct direct {

 ino_t d_ino;

 char d_name[DIRSIZ];

};

ino_t определен в V7 <sys/types.h> как 'typedef unsigned int into_t;'. Поскольку на PDP-11 int является 16-разрядным, таким же является и ino_t. Такая организация упрощала непосредственное чтение каталогов; поскольку размер элемента был фиксирован, код был простым. (Единственно, за чем нужно было следить, это то, что полное 14-символьное d_name не завершалось символом NUL.)

Управление содержанием каталога для системы также было простым. Когда файл удалялся из каталога, система заменяла номер индекса двоичным нулем, указывая, что элемент каталога не используется. Новые файлы могли потом использовать пустой элемент повторно. Это помогало поддерживать размер самих файлов каталогов в приемлемых рамках. (По соглашению, номер индекса 1 не используется; первым используемым индексом всегда является 2. Дополнительные сведения приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».)

Современные системы предоставляют длинные имена файлов. Каждый элемент каталога имеет различную длину, с обычным ограничением для компонента имени файла каталога в 255 байтов. Далее мы увидим, как читать на современных системах содержимое каталога. Также в современных системах номера индексов 32 (или даже 64!) разрядные.

5.1.3. Прямые ссылки

Когда файл создается с помощью open() или creat(), система находит не использующийся индекс и присваивает его новому файлу. Она создает для файла элемент каталога с именем файла и номером индекса. Опция -i команды ls отображает номер индекса.

$ echo hello, world > message /* Создать новый файл */

$ ls -il message /* Показать также номер индекса */

228786 -rw-r--r-- 1 arnold devel 13 May 4 15:43 message

Поскольку элементы каталога связывают имена файлов с индексами, у одного файла может быть несколько имен. Каждый элемент каталога, ссылающийся на один и тот же индекс, называется ссылкой (link) или прямой ссылкой (hard link) на файл. Ссылки создаются с помощью команды ln. Она используется следующим образом: 'ln старый_файл новый_файл'.

$ ln message msg /* Создать ссылку */

$ cat msg /* Показать содержание нового имени */

hello, world

$ ls -il msg message /* Показать номера индексов */

228786 -rw-r--r-- 2 arnold devel 13 May 4 15:43 message

228786 -rw-r--r-- 2 arnold devel 13 May 4 15:43 msg

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

Нельзя не подчеркнуть: прямые ссылки все относятся к одному и тому же файлу. Если вы измените один файл, изменятся и все остальные:

$ echo "Hi, how ya doin' ?" > msg /* Изменить файл через новое имя */

$ cat message /* Показать содержание через старое имя */

Hi, how ya doin' ?

$ ls -il message msg /* Отобразить сведения. Размер изменился */

228786 -rw-r--r-- 2 arnold devel 19 May 4 15:51 message

228786 -rw-r--r-- 2 arnold devel 19 May 4 15:51 msg

Хотя мы создали две ссылки на один файл в одном каталоге, прямые ссылки не обязательно должны находиться в одном и том же каталоге; они могут находиться в любом каталоге в той же самой файловой системе. (Несколько подробнее это обсуждается в разделе 5.1.6 «Символические ссылки».)

Вдобавок, вы можете создать ссылку на файл, который вам не принадлежит, если у вас есть право записи в каталоге, в котором вы создаете ссылку. (Такой файл сохраняет все атрибуты первоначального файла: владельца, права доступа и т.д. Это потому, что это и есть оригинальный файл; просто он получил дополнительное имя.) Код уровня пользователя не может создать прямую ссылку на каталог.

После удаления ссылки создание еще одного файла с прежним именем создает новый файл:

$ rm message /* Удалить старое имя */

$ echo "What's happenin?" > message /* Повторно использовать имя */

$ ls -il msg message /* Отобразить сведения */

228794 -rw-r--r-- 1 arnold devel 17 May 4 15:58 message

228786 -rw-r--r-- 1 arnold devel 19 May 4 15:51 msg

Обратите внимание, что теперь счетчик ссылок каждого из файлов равен 1. На уровне С ссылки создаются с помощью системного вызова link():

#include <unistd.h> /* POSIX */

int link(const char *oldpath, const char *newpath);

При успешном создании ссылки возвращается 0, в противном случае (-1), при этом errno отражает ошибку. Важным-случаем ошибки является тот, когда newpath уже существует. Система не удалит его для вас, поскольку попытка сделать это может вызвать несовместимости в файловой системе.

5.1.3.1. Программа GNU link

Программа ln сложная и большая. Однако, GNU Coreutils содержит несложную программу link, которая просто вызывает link() со своими двумя аргументами. Следующий пример показывает код из файла link.с, не относящиеся к делу части удалены. Номера строк относятся к действительному файлу.

20  /* Обзор реализации:

21

22     Просто вызывает системную функцию 'link' */

23

    /* ...Операторы #include для краткости опущены... */

34

35  /* Официальное имя этой программы (например, нет префикса 'g'). */

36  #define PROGRAM_NAME "link"

37

38  #define AUTHORS "Michael Stone"

39

40  /* Имя, под которым была запущена данная программа. */

41  char *program_name;

42

43  void

44  usage(int status)

45  {

     /*  ... для краткости опущено... */

62  }

63

64  int

65  main(int argc, char **argv)

66  {

67   program_name = argv[0];

68   setlocale(LC_ALL, "");

69   bindtextdomain(PACKAGE, LOCALEDIR);

70   textdomain(PACKAGE);

71

72   atexit(close_stdout);

73

74   parse_long_options(argc, argv, PROGRAM_NAME, GNU_PACKAGE,

75    VERSION, AUTHORS, usage);

76

77   /* Вышеприведенное обрабатывает --help и --version.

78      Поскольку других вызовов getopt нет, обработать здесь '--'. */

79   if (1 < argc && STREQ(argv[1], "--"))

80   {

81    --argc;

82    ++argv;

83   }

84

85   if (argc < 3)

86   {

87    error(0, 0, _("too few arguments"));

88    usage(EXIT_FAILURE);

89   }

90

91   if (3 < argc)

92   {

93    error(0, 0, _("too many arguments"));

94    usage(EXIT_FAILURE);

95   }

96

97   if (link(argv[1], argv[2]) != 0)

98    error(EXIT_FAILURE, errno, _("cannot create link %s to %s"),

99     quote_n(0, argv[2]), quote_n(1, argv[1]));

100

101  exit(EXIT_SUCCESS);

102 }

Строки 67–75 являются типичным шаблоном Coreutils, устанавливающими интернациональные настройки, выход по завершении и анализ аргументов. Строки 79–95 гарантируют, что link вызывается лишь с двумя аргументами. Сам системный вызов link() осуществляется в строке 97 (Функция quote_n() обеспечивает отображение аргументов в стиле, подходящем для текущей локали; подробности сейчас несущественны.)

5.1.3.2. Точка и точка-точка

Завершая обсуждение ссылок, давайте взглянем на то, как обрабатываются специальные имена '.' и '..'. На самом деле они просто являются прямыми ссылками. В первом случае '.' является прямой ссылкой на каталог, содержащий ее, а '..' — прямой ссылкой на родительский каталог. Операционная система создает для вас эти ссылки; как упоминалось ранее, код уровня пользователя не может создать прямую ссылку на каталог. Этот пример иллюстрирует ссылки:

$ pwd /* Отобразить текущий каталог */

/tmp

$ ls -ldi /tmp /* Показать номер его индекса */

225345 drwxrwxrwt 14 root root 4096 May 4 16:15 /tmp

$ mkdir x /* Создать новый каталог */

$ ls -ldi x /* И показать номер его индекса */

52794 drwxr-xr-x 2 arnold devel 4096 May 4 16:27 x

$ ls -ldi x/. x/.. /* Показать номера индексов . И .. */

52794 drwxr-xr-x 2 arnold devel 4096 May 4 16:27 x/.

225345 drwxrwxrwt 15 root root 4096 May 4 16:27 x/..

Родительский каталог корневого каталога (/..) является особым случаем; мы отложим его обсуждение до главы 8 «Файловые системы и обход каталогов».

5.1.4. Переименование файлов

При данном способе отображения элементами каталога имен на номера индексов, переименование файла концептуально очень просто:

1. Если новое имя файла обозначает существующий файл, сначала удалить этот файл.

2. Создать новую ссылку на файл через новое имя.

3. Удалить старое имя (ссылку) для файла. (Удаление имен обсуждается в следующем разделе.)

Ранние версии команды mv работали таким способом. Однако, при таком способе переименование файла не является атомарным; т.е. оно не осуществляется посредством одной непрерываемой операции. И на сильно загруженной системе злонамеренный пользователь мог бы воспользоваться условиями состояния гонки[51], разрушая операцию переименования и подменяя оригинальный файл другим.

По этой причине 4.2 BSD ввело системный вызов rename():

#include <stdio.h> /* ISO С */

int rename(const char *oldpath, const char *newpath);

На системах Linux операция переименования является атомарной; справочная страница утверждает:

Если newpath уже существует, он будет атомарно замещен .., таким образом, что при попытке другого процесса получить доступ к newpath он никогда не обнаружит его отсутствующим.

Если newpath существует, но по какой-либо причине операция завершается неудачей, rename гарантирует, что экземпляр newpath останется на месте. Однако, в ходе переписывания возможно будет окно, в котором как oldpath, так и newpath ссылаются на переименовываемый файл.

Как и в случае с другими системными вызовами, возвращенный 0 означает успех, а (-1) означает ошибку.

5.1.5. Удаление файла

Удаление файла означает удаление элемента каталога для файла и уменьшение счетчика ссылок на файл, который содержится в индексе. Содержимое файла и дисковые блоки, в котором оно размешается, не освобождаются до тех пор, пока счетчик ссылок не достигнет нуля.

Системный вызов называется unlink():

#include <unistd.h> /* POSIX */


int unlink(const char *pathname);

В нашем обсуждении ссылок на файлы имя имеет смысл; этот вызов удаляет данную ссылку (элемент каталога) для файла. Она возвращает 0 в случае успеха и -1 при ошибке. Возможность удаления файла требует права записи лишь для каталога, а не для самого файла. Этот факт может сбивать с толку, особенно начинающих пользователей Linux/Unix. Однако, поскольку операция в каталоге одна, это имеет смысл; меняется именно содержимое каталога, а не содержимое файла[52].

5.1.5.1. Удаление открытых файлов

С самых первых дней Unix было возможно удалять открытые файлы. Просто вызовите unlink() с именем файла после успешного вызова open() или creat().

На первый взгляд, это кажется странным. Поскольку система освобождает блоки данных, когда счетчик ссылок на файл достигает нуля, возможно ли использовать открытый файл?

Ответ — да, вы можете продолжить использовать открытый файл обычным способом. Система знает, что файл открыт, поэтому она откладывает освобождение хранилища файла до тех пор, пока не будет закрыт последний дескриптор файла. Когда файл вообще больше не используется, память освобождается.

Эта операция также оказывается полезной: это простой способ для программы получить временный файл, который гарантированно будет и конфиденциальным, и автоматически освобождаемым по завершении использования.

/* Получение конфиденциального временного хранилища,

   проверка ошибок для краткости опущена */

int fd;

mode_t mode = O_CREAT | O_EXCL | O_TRUNC | O_RDWR;

fd = open("/tmp/myfile", mode, 0000); /* Открыть файл */

unlink("/tmp/myfile"); /* Удалить его */

/* ... продолжить использование файла... *

close(fd); /* Закрыть файл, освободить память */

Недостатком такого подхода является то, что вышедшее из-под контроля приложение может заполнить систему открытыми, но анонимными файлами, в этом случае администраторам придется попытаться найти и завершить этот процесс. В прежние дни могли потребоваться перезагрузка и проверка целостности файловой системы; к счастью, на современных системах это требуется исключительно редко.

5.1.5.2. Использование ISO С: remove()

ISO С предоставляет для удаления файлов функцию remove(); она предназначена в качестве обшей функции, годной для любой системы, поддерживающей ISO С, а не только для Unix и GNU/Linux:

#include <stdio.h> /* ISO С */


int remove(const char *pathname);

Хотя технически это не системный вызов, возвращаемое значение в том же стиле: 0 в случае успеха и -1 при ошибке, причем errno содержит значение ошибки.

В GNU/Linux remove() использует для удаления файлов системный вызов unlink(), а для удаления каталогов — системный вызов rmdir() (обсуждаемый далее в главе). (На более старых системах GNU/Linux, не использующих GLIBC, remove() является псевдонимом для unlink(); поэтому для каталогов завершается неудачей. Если у вас такая система, вам, возможно, следует ее обновить.)

5.1.6. Символические ссылки

Мы начали главу с обсуждения разделов, файловых систем и индексов. Мы также увидели, что элементы каталога связывают имена с номерами индексов. Поскольку элементы каталога не содержат другой информации, прямые ссылки ограничены файлами внутри одной и той же файловой системы. Это должно быть; нет способа отличить индекс 2341 одной файловой системы от индекса 2341 другой файловой системы. Вот что случится, если мы попытаемся это сделать:

mount /* Показать использующиеся файловые системы */

/dev/hda2 on / type ext3 (rw)

/dev/hda5 on /d type ext3 (rw)

...

$ ls -li /tmp/message /* Предыдущий пример был в файловой системе / */

228786 -rw-r--r-- 2 arnold devel 19 May 4 15:51 /tmp/message

$ cat /tmp/message

Hi, how ya doin' ?

$ /bin/pwd /* Текущий каталог в другой файловой системе */

/d/home/arnold

$ ln /tmp/message . /* Попытка создать ссылку */

ln: creating hard link './message' to '/tmp/message': Invalid cross-device link

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

Чтобы обойти это ограничение, 4.2 BSD ввело символические ссылки (symbolic links, называемые также soft links). Символическая ссылка является особой разновидностью файла (также, как особой разновидностью файла является каталог). Содержимое этого файла представляет собой путь к файлу, на который данный файл «указывает». Все современные Unix-системы, включая Linux, предусматривают символические ссылки; конечно, они теперь являются частью POSIX.

Символические ссылки могут ссылаться на любой файл в системе. Они могут также ссылаться на каталоги. Это упрощает перемещение каталогов с места на место, когда на старом месте остается символическая ссылка, указывающая на новое положение.

При обработке имени файла система отмечает символические ссылки и осуществляет требуемые действия в файле или каталоге, который указан. Символические ссылки создаются с помощью опции -s команды ln:

$ /bin/pwd /* Где мы находимся */

/d/home/arnold /* В другой файловой системе */

$ ln -s /tmp/message ./hello /* Создать символическую ссылку */

$ cat hello /* Использовать ее */

Hi, how ya doin' ?

$ ls -l hello /* Отобразить информацию о ней */

lrwxrwxrwx 1 arnold devel 12 May 4 16:41 hello -> /tmp/message

Файл, на который указывает ссылка, необязательно должен существовать. Система обнаруживает это во время исполнения и действует соответствующим образом:

$ rm /tmp/message /* Удалить указываемый файл */

$ cat ./hello /* Попытка использования через символическую ссылку */

cat: ./hello: No such file or directory

$ echo hi again > hello /* Создать новое содержание файла */

$ ls -l /tmp/message /* Показать информацию об указываемом файле */

-rw-r--r-- 1 arnold devel 9 May 4 16:45 /tmp/message

$ cat /tmp/message /* ...и содержание */

hi again

Символические ссылки создаются с помощью системного вызова symlink():

#include <unistd.h> /* POSIX */


int symlink(const char *oldpath, const char *newpath);

Аргумент oldpath содержит указываемый файл или каталог, a newpath является именем создаваемой символической ссылки. При успехе возвращается 0, а при ошибке (-1), возможные значения errno см. в справочной странице для symlink(2). У символических ссылок есть свои недостатки:

• Они занимают лишнее дисковое пространство, требуя отдельного индекса и блока данных. Прямые ссылки занимают лишь элемент каталога.

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

• Они могут создать «циклы». Рассмотрите следующее:

$ rm -f a b /* Убедиться, что 'a' и 'b' не существуют */

$ ln -s a b /* Создать ссылку старого файла 'a' на новый 'b' */

$ ln -s b a /* Создать ссылку старого файла 'b' на новый 'a' */

$ cat а /* Что случилось? */

cat: a: Too many levels of symbolic links

Ядро должно быть способно определить такой случай и выдать сообщение об ошибке.

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

5.2. Создание и удаление каталогов

Создание и удаление каталогов просто. Двумя системными вызовами, что неудивительно, являются mkdir() и rmdir() соответственно:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>


int mkdir(const char *pathname, mode_t mode);


#include <unistd.h> /* POSIX */


int rmdir(const char *pathname);

Оба возвращают 0 при успехе и (-1) при ошибке, с соответствующим errno. Аргумент mode для mkdir() представляет права доступа, которые должны быть использованы для каталога. Он полностью идентичен аргументам mode для creat() и open(), обсуждавшимся в разделе 4.6 «Создание файлов».

Обе функции обрабатывают '.' и '..' в создаваемом или удаляемом каталоге. Перед удалением каталог должен быть пуст; если это не так, errno устанавливается в ENOTEMPTY. (В данном случае, «пуст» означает, что каталог содержит только '.' и '..'.)

Новым каталогам, как и всем файлам, присваивается идентификационный номер группы. К сожалению, его работа запутана. Мы отложим обсуждение до раздела 11.5.1 «Группа по умолчанию для новых файлов и каталогов».

Обе функции работают на одном уровне каталога за раз. Если /somedir существует, a /somedir/sub1 нет, 'mkdir("/somedir/sub1/sub2")' завершится неудачей. Каждый компонент в длинном пути должен создаваться отдельно (в соответствии с опцией -р mkdir, см. mkdir(1)).

Также, если pathname завершается символом '/', на некоторых системах mkdir() и rmdir() потерпят неудачу, а на других нет. Следующая программа, ch05-trymkdir.с, демонстрирует оба аспекта.

1  /* ch05-trymkdir.c --- Демонстрирует поведение mkdir().

2     Любезность Nelson H.F. Beebe. */

3

4  #include <stdio.h>

5  #include <stdlib.h>

6  #include <errno.h>

7

8  #if !defined(EXIT_SUCCESS)

9  #define EXIT_SUCCESS 0

10 #endif

11

12 void do_test(const char *path)

13 {

14  int retcode;

15

16  errno = 0;

17  retcode = mkdir(path, 0755);

18  printf("mkdir(\"%s\") returns %d: errno = %d [%s)\n",

19   path, retcode, errno, strerror(errno));

20 }

21

22 int main(void)

23 {

24  do_test("/tmp/t1/t2/t3/t4"); /*Попытка создания в подкаталоге*/

25  do_test("/tmp/t1/t2/t3");

26  do_test("/tmp/t1/t2");

27  do_test("/tmp/t1");

28

29  do_test("/tmp/u1"); /* Создать подкаталоги */

30  do_test("/tmp/u1/u2");

31  do_test("/tmp/u1/u2/u3");

32  do_test("/tmp/u1/u2/u3/u4");

33

34  do_test("/tmp/v1/"); /* Как обрабатывается завершающий '/'? */

35  do_test("/tmp/v1/v2/");

36  do_test("/tmp/v1/v2/v3/");

37  do_test("/tmp/v1/v2/v3/v4/");

38

39  return(EXIT_SUCCESS);

40 }

Вот результаты для GNU/Linux:

$ ch05-trymkdir

mkdir("/tmp/t1/t2/t3/t4") returns -1: errno = 2 [No such file or directory)

mkdir("/tmp/t1/t2/t3") returns -1: errno = 2 [No such file or directory)

mkdir("/tmp/t1/t2") returns -1: errno = 2 [No such file or directory]

mkdir("/tmp/t1") returns 0: errno = 0 [Success]

mkdir("/tmp/u1") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2/u3") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2/u3/u4") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/v2/") returns 0: errno = 0 (Success]

mkdir("/tmp/v1/v2/v3/") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/v2/v3/v4/") returns 0: errno = 0 [Success]

Обратите внимание, как GNU/Linux принимает завершающий слеш. Не все системы так делают.

5.3. Чтение каталогов

В оригинальных системах Unix чтение содержимого каталогов было просто. Программа открывала каталог с помощью open() и непосредственно читала двоичные структуры struct direct, по 16 байтов за раз. Следующий фрагмент кода из программы V7 rmdir[53], строки 60–74. Он показывает проверку на пустоту каталога.

60 if ((fd = open(name, 0)) < 0) {

61  fprintf(stderr, "rmdir: %s unreadable\n", name);

62  ++Errors;

63  return;

64 }

65 while (read(fd, (char*)&dir, sizeof dir) == sizeof dir) {

66  if (dir.d_ino == 0) continue;

67  if (!strcmp(dir.d_name, ".") || !strcmp(dir.d_name, ".."))

68   continue;

69  fprintf(stderr, "rmdir: %s not empty\n", name);

70  ++Errors;

71  close(fd);

72  return;

73 }

74 close(fd);

В строке 60 каталог открывается для чтения (второй аргумент равен 0, что означает O_RDONLY). В строке 65 читается struct direct. В строке 66 проверяется, не является ли элемент каталога пустым, т. е. с номером индекса 0. Строки 67 и 68 проверяют на наличие '.' и '..'. По достижении строки 69 мы знаем, что было встречено какое-то другое имя файла, следовательно, этот каталог не пустой.

(Тест '!strcmp(s1, s2)' является более короткой формой 'strcmp(s1, s2) == 0', т.е. проверкой совпадения строк. Стоит заметить, что мы рассматриваем '!strcmp(s1, s2)' как плохой стиль. Как сказал однажды Генри Спенсер (Henry Spencer), «strcmp() это не boolean!».)

Когда 4.2BSD представило новый формат файловой системы, который допускал длинные имена файлов и обеспечивал лучшую производительность, были также представлены несколько новых функций для абстрагирования чтения каталогов. Этот набор функций можно использовать независимо от того, какова лежащая в основе файловая система и как организованы каталоги. Основная ее часть стандартизована POSIX, а программы, использующие ее, переносимы между системами GNU/Linux и Unix.

5.3.1. Базовое чтение каталогов

Элементы каталогов представлены struct dirent (не то же самое, что V7 struct direct!):

struct dirent {

 ...

 ino_t d_ino;      /* расширение XSI --- см. текст */

 char d_name[...]; /* О размере этого массива см. в тексте */

 ...

};

Для переносимости POSIX указывает лишь поле d_name, которое является завершающимся нулем массивом байтов, представляющим часть элемента каталога с именем файла. Размер d_name стандартом не указывается, кроме того, что там перед завершающим нулем может быть не более NAME_MAX байтов. (NAME_MAX определен в <limits.h>.) Расширение XSI POSIX предусматривает поле номера индекса d_ino.

На практике, поскольку имена файлов могут быть различной длины, a NAME_MAX обычно довольно велико (подобно 255), struct dirent содержит дополнительные члены, которые помогают вести на диске учет элементов каталогов с переменными длинами. Эти дополнительные члены не существенны для обычного кода.

Следующие функции предоставляют интерфейс чтения каталогов:

#include <sys/types.h> /* POSIX */

#include <dirent.h>


DIR *opendir(const char *name);   /* Открыть каталог для чтения */

struct dirent *readdir(DIR *dir); /* Вернуть struct dirent за раз */

int closedir(DIR *dir);           /* Закрыть открытый каталог */

void rewinddir(DIR *dirp);        /* Вернуться в начало каталога */

Тип DIR является аналогом типа FILE в <stdio.h>. Это непрозрачный тип, что означает, что код приложения не должен знать, что находится внутри него; его содержимое предназначено для использования другими процедурами каталогов. Если opendir() возвращает NULL, именованный каталог не может быть открыт для чтения, а errno содержит код ошибки.

Открыв переменную DIR*, можно использовать ее для получения указателя на struct dirent, представляющего следующий элемент каталога. readdir() возвращает NULL, если достигнут конец каталога[54] или произошла ошибка.

Наконец, closedir() является аналогичной функции fclose() в <stdio.h>; она закрывает открытую переменную DIR*. Чтобы начать с начала каталога, можно использовать функцию rewinddir().

Имея в распоряжении (или по крайней мере в библиотеке С) эти функции, мы можем написать небольшую программу catdir, которая «отображает» содержимое каталога. Такая программа представлена в ch05-catdir.с:

1  /* ch05-catdir.с - Демонстрация opendir(), readdir(), closedir(). */

2

3  #include <stdio.h> /* для printf() и т.д. */

4  #include <errno.h> /* для errno */

5  #include <sys/types.h> /* для системных типов */

6  #include <dirent.h> /* для функций каталога */

7

8  char *myname;

9  int process(char *dir);

10

11 /* main --- перечисление аргументов каталога */

12

13 int main(int argc, char **argv)

14 {

15  int i;

16  int errs = 0;

17

18  myname = argv[0];

19

20  if (argc == 1)

21   errs = process("."); /* по умолчанию текущий каталог */

22  else

23   for (i = 1; i < argc; i++)

24    errs += process(argv[i]);

25

26  return (errs != 0);

27 }

Эта программа вполне подобна ch04-cat.c (см. раздел 4.2 «Представление базовой структуры программы»); функция main() почти идентична. Главное различие в том, что по умолчанию используется текущий каталог, если нет аргументов (строки 20–21).

29 /*

30  * process --- сделать что-то с каталогом, в данном случае,

31  * вывести пары индекс/имя в стандартный вывод.

32  * Возвращает 0, если все OK, иначе 1.

33  */

34

35 int

36 process(char *dir)

37 {

38  DIR *dp;

39  struct dirent *ent;

40

41  if ((dp = opendir(dir)) == NULL) {

42   fprintf(stderr, "%s: %s: cannot open for reading: %s\n",

43   myname, dir, strerror(errno));

44   return 1;

45  }

46

47  errno = 0;

48  while ((ent = readdir(dp)) != NULL)

49   printf("%8ld %s\n", ent->d_ino, ent->d_name);

50

51  if (errno != 0) {

52   fprintf(stderr, "%s: %s: reading directory entries: %s\n",

53   myname, dir, strerror(errno));

54   return 1;

55  }

56

57  if (closedir(dp) != 0) {

58   fprintf(stderr, "%s: %s: closedir: %s\n",

59    myname, dir, strerror(errno));

60   return 1;

61  }

62

63  return 0;

64 }

Функция process() делает всю работу и большую часть кода проверки ошибок. Основой функции являются строки 48 и 49:

while ((ent = readdir(dp)) != NULL)

printf("%8ld %s\n", ent->d_ino, ent->d_name);

Этот цикл читает элементы каталога, по одной за раз, до тех пор, пока readdir() не возвратит NULL. Тело цикла отображает для каждого элемента номер индекса и имя файла. Вот что происходит при запуске программы:

$ ch05-catdir /* По умолчанию текущий каталог */

639063 .

639062 ..

639064 proposal.txt

639012 lightsabers.url

688470 code

638976 progex.texi

639305 texinfo.tex

639007 15-processes.texi

639011 00-preface.texi

639020 18-tty.texi

638980 Makefile

639239 19-i18n.texi

...

Вывод никаким образом не сортируется; он представляет линейное содержимое каталога. (Как сортировать содержимое каталога мы опишем в разделе 6.2 «Функции сортировки и поиска»).

5.3.1.1. Анализ переносимости

Есть несколько соображений по переносимости. Во-первых, не следует предполагать, что двумя первыми элементами, возвращаемыми readdir(), всегда будут '.' и '..'. Многие файловые системы используют организацию каталогов, которые отличаются от первоначального дизайна Unix, и '.' и '..' могут быть в середине каталога или даже вовсе не присутствовать[55].

Во-вторых, стандарт POSIX ничего не говорит о возможных значениях d_info. Он говорит, что возвращенные структуры представляют элементы каталогов для файлов; это предполагает, что readdir() не возвращает пустые элементы, поэтому реализация GNU/Linux readdir() не беспокоится с возвратом элементов, когда 'd_ino == 0'; она переходит к следующему действительному элементу.

Поэтому по крайней мере на системах GNU/Linux и Unix маловероятно, что d_ino когда-нибудь будет равен нулю. Однако, лучше по возможности вообще избегать использования этого поля.

Наконец, некоторые системы используют d_fileno вместо d_ino в struct dirent. Знайте об этом, когда нужно перенести на такие системы код, читающий каталоги.

Косвенные системные вызовы
«Не пробуйте это дома, дети!»

- М-р Wizard -

Многие системные вызовы, такие, как open(), read() и write(), предназначены для вызова непосредственно из кода пользователя: другими словами, из кода, который пишете вы как разработчик GNU/Linux.

Однако, другие системные вызовы существуют лишь для того, чтобы дать возможность реализовать стандартные библиотечные функции более высокого уровня, и никогда не должны вызываться непосредственно. Одним из таких системных вызовов является GNU/Linux getdents(); он читает несколько элементов каталога в буфер, предоставленный вызывающим — в данном случае, кодом реализации readdir(). Затем код readdir() возвращает действительные элементы каталога, по одному за раз, пополняя при необходимости буфер.

Эти системные вызовы только-для-библиотечного-использования можно отличить от вызовов для-использования-пользователем по их представлению в странице справки. Например, из getdents(2).

ИМЯ

  getdents - получить элементы каталога

ОПИСАНИЕ

  #include <unistd.h>

  #include <linux/types.h>

  #include <linux/dirent.h>

  #include <linux/unistd.h>

  _syscall3(int, getdents, uint, fd, struct dirent*,

            dirp, uint, count);

  int getdents(unsigned int fd, struct dirent *dirp,

               unsigned int count);

Любой системный вызов, использующий макрос _syscallX(), не должен вызываться кодом приложения. (Дополнительную информацию об этих вызовах можно найти в справочной странице для intro(2); вам следует прочесть эту справочную страницу, если вы этого еще не сделали.)

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

5.3.1.2. Элементы каталогов Linux и BSD

Хотя мы только что сказали, что вам следует использовать лишь члены d_ino и d_name структуры struct dirent, стоит знать о члене d_type в struct dirent BSD и Linux. Это значение unsigned char, в котором хранится тип файла, имя которого находится в элементе каталога:

struct dirent {

 ...

 ino_t d_ino;          /* Как ранее */

 char d_name[...];     /* Как ранее */

 unsigned char d_type; /* Linux и современная BSD */

 ...

};

d_type может принимать любые значения, описанные в табл. 5.1.


Таблица 5.1. Значения для d_type

Имя Значение
DT_BLK Файл блочного устройства
DT_CHR Файл символьного устройства
DT_DIR Каталог
DT_FIFO FIFO или именованный канал
DT_LNK Символическая ссылка
DT_REG Обычный файл
DT_SOCK Сокет
DT_UNKNOWN Неизвестный тип файла
DT_WHT Нет элемента (только системы BSD)
Знание типа файла просто путем чтения элемента каталога очень удобно; это может сэкономить на возможно дорогом системном вызове stat(). (Вызов stat() вскоре будет описан в разделе 5.4.2 «Получение информации о файле».)

5.3.2. Функции размещения каталогов BSD

Иногда полезно отметить текущее положение в каталоге для того, чтобы иметь возможность позже к нему вернуться. Например, вы пишете код, обходящий дерево каталога, и хотите рекурсивно входить в каждый подкаталог, когда его проходите. (Как отличить файлы от каталогов обсуждается в следующем разделе). По этой причине первоначальный интерфейс BSD включал две дополнительные процедуры:

#include <dirent.h> /* XSI */

/* Предупреждение: POSIX XSI использует для обеих функций long, а не off_t */


off_t telldir(DIR *dir);              /* Вернуть текущее положение */

void seekdir(DIR *dir, off_t offset); /* Переместиться в данное положение */

Эти процедуры подобны функциям ftell() и fseek() и <stdio.h>. Они возвращают текущее положение в каталоге и устанавливают текущее положение в ранее полученное значение соответственно.

Эти процедуры включены в часть XSI стандарта POSIX, поскольку они имеют смысл лишь для каталогов, которые реализованы с линейным хранением элементов каталога

Помимо предположений, сделанных относительно лежащей в основе структуры каталога, эти процедуры рискованнее использовать, чем простые процедуры чтения каталога. Это связано с тем, что содержание каталога может изменяться динамически: когда файлы добавляются или удаляются из каталога, операционная система приводит в порядок содержание каталога. Поскольку элементы каталога имеют различный размер, может оказаться, что сохраненное ранее абсолютное смещение больше не представляет начало элемента каталога! Поэтому мы не рекомендуем вам использовать эти функции, если вам они действительно не нужны[56].

5.4. Получение информации о файлах

Чтение каталога для получения имен файлов лишь половина дела. Получив имя файла, нужно знать, как получить остальную информацию, связанную с файлом, такую, как тип файла, права доступа к нему, владельца и т.д.

5.4.1. Типы файлов Linux

Linux (и Unix) поддерживает следующие различные типы файлов:

Обычные файлы

Как предполагает имя, данный тип используется для данных, исполняемых программ и всего прочего, что вам может понравиться. В листинге 'ls -l' они обозначаются в виде первого символа '-' поля прав доступа (режима).

Каталоги

Специальные файлы для связывания имен файлов с индексами. В листинге 'ls -l' они обозначаются первым символом d поля прав доступа.

Символические ссылки

Как описано ранее в главе. В листинге 'ls -l' обозначаются первым символом l (буква «эль», не цифра 1) поля прав доступа.

Устройства

Файлы, представляющие как физические аппаратные устройства, так и программные псевдоустройства. Есть две разновидности:

Блочные устройства

Устройства, ввод/вывод которых осуществляется порциями некоторого фиксированного размера физической записи, такие, как дисковые и ленточные приводы. Доступ к таким устройствам осуществляется через буферный кэш ядра. В листинге 'ls -l' они обозначаются первым символом b поля прав доступа.

Символьные устройства

Известны также как непосредственные (raw) устройства. Первоначально символьными устройствами были те, в которых ввод/вывод осуществлялся по несколько байтов за раз, как в терминалах. Однако, символьное устройство используется также для непосредственного ввода/вывода на блочные устройства, такие, как ленты и диски, минуя буферный кэш[57]. В листинге 'ls -l' они отображаются первым символом с поля прав доступа.

Именованные каналы (named pipes)

Известны также файлы FIFO («first-in first-out» — «первым вошел, первым обслужен»). Эти специальные файлы действуют подобно конвейерам (pipes); данные, записанные в них одной программой, могут быть прочитаны другой; данные не записываются на диск и не считываются с диска. FIFO создаются с помощью команды mkfifo; они обсуждаются в разделе 9.3.2 «FIFO». В листинге 'ls -l' они отображаются первым символом p поля прав доступа.

Сокеты

Сходные по назначению с именованными каналами[58], они управляются системными вызовами межпроцессных взаимодействий (IPC) сокетов, и мы не будем в данной книге иметь с ними дело в других отношениях. В листинге 'ls -l' они отображаются первым символом s поля прав доступа.

5.4.2. Получение информации о файле

Три системных вызова возвращают информацию о файлах:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <unistd.h>


int stat(const char *file_name, struct stat *buf);

int fstat(int filedes, struct stat *buf);

int lstat(const char *file_name, struct stat *buf);

Функция stat() получает имя файла с путем и возвращает сведения о данном файле. Она следует по символическим ссылкам; т. е. при применении к символической ссылке stat() возвращает информацию об указываемом файле, а не о самой ссылке. В тех случаях, когда вам нужно знать, является ли файл символической ссылкой, используйте вместо нее функцию lstat(); последняя не следует по символическим ссылкам.

Функция fstat() получает сведения об уже открытом файле. Это особенно полезно для дескрипторов файлов 0, 1 и 2 (стандартных ввода, вывода и ошибки), которые уже открыты при запуске процесса. Однако, она может использоваться с любым открытым файлом. (Дескриптор открытого файла никогда не будет относиться к символической ссылке; убедитесь, что понимаете, почему.)

Значение, переданное в качестве второго параметра, должно быть адресом struct stat, объявленной в <sys/stat.h>. Как в случае с struct dirent, struct stat содержит по крайней мере следующие члены:

struct stat {

 ...

 dev_t st_dev;         /* устройство */

 ino_t st_ino;         /* индекс */

 mode_t st_mode;       /* тип и защита */

 nlink_t st_nlink;     /* число прямых (hard) ссылок */

 uid_t st_uid;         /* ID владельца */

 gid_t st_gid;         /* ID группы */

 dev_t st_rdev;        /* тип устройства (блочное или символьное) */

 off_t st_size;        /* общий размер в байтах */

 blksize_t st_blksize; /* размер блока для ввода/вывода файл, с-мы */

 blkcnt_t st_blocks;   /* число выделенных блоков */

 time_t st_atime;      /* время последнего доступа */

 time_t st_mtime;      /* время последнего изменения */

 time_t st_ctime;      /* время последнего изменения индекса */

 ...

};

(Размещение на разных системах может быть разное.) Эта структура использует ряд определенных через typedef типов. Хотя они все (обычно) целые типы, использование специально определенных типов позволяет использовать для них различные размеры на разных системах. Это сохраняет переносимость кода пользователя, который их использует. Вот более полное описание каждого поля.

st_dev

Устройство для монтируемой файловой системы. У каждой монтируемой файловой системы уникальное значение st_dev.

st_ino

Номер индекса файла в пределах файловой системы. Пара (st_dev, st_ino) уникально идентифицирует файл.

st_mode

Тип файла и права доступа к нему, закодированные в одном поле. Вскоре мы рассмотрим, как извлечь эту информацию.

st_nlink

Число прямых ссылок на файл (счетчик ссылок). Может равняться нулю, если файл был удален после открытия.

st_uid

UID файла (номер владельца).

st_gid

GID файла (номер группы).

st_rdev

Тип устройства, если файл является блочным или символьным устройством. st_rdev содержит закодированную информацию об устройстве. Вскоре мы увидим, как извлечь эту информацию. Это поле не имеет смысла, если файл не является блочным или символьным устройством.

st_size

Логический размер файла. Как упоминалось в разделе 4.5 «Произвольный доступ: перемещение внутри файла», файл может содержать в себе дыры, в этом случае размер может не отражать истинного значения занимаемого им места.

st_blksize

«Размер блока» файла. Представляет предпочтительный размер блока данных для ввода/вывода данных в или из файла. Почти всегда превышает размер физического сектора диска. У более старых систем Unix нет этого поля (или поля st_blocks) в struct stat. Для файловых систем Linux ext2 и ext3 это значение составляет 4096.

st_blocks

Число «блоков», используемых файлом. В Linux это значение представлено в единицах 512-байтных блоков. На других системах размер блока может быть различным, проверьте свою локальную страницу справки для stat(2). (Это число происходит от константы DEV_BSIZE в <sys/param.h>. Эта константа не стандартизована, но довольно широко используется в системах Unix.)

Число блоков может быть больше, чем 'st_size / 512'; кроме блоков данных, файловая система может использовать дополнительные блоки для хранения размещений блоков данных. Это особенно необходимо для больших файлов.

st_atime

Время доступа к файлу; т.е. когда в последний раз читались данные файла.

st_mtime

Время модификации файла; т е. когда в последний раз данные файла записывались или урезались.

st_ctime

Время изменения индекса файла. Указывает время последнего изменения служебных данных файла, таких, как права доступа или владелец.

ЗАМЕЧАНИЕ. Поле st_ctime не является «временем создания»! В системе Linux или Unix нет такой вещи. Часть более ранней документации называла поле st_ctime временем создания. Это была вводящая в заблуждение попытка упростить представление служебных данных файла

Тип time_t, использованный для полей st_atime, st_mtime и st_ctime, представляет дату и время. Эти относящиеся ко времени значения иногда называют временными метками (timestamps). Обсуждение того, как использовать значение time_t, отложено до раздела 6.1 «Время и даты». Подобным же образом типы uid_t и gid_t представляют номера владельца и группы, которые обсуждаются в разделе 6.3 «Имена пользователя и группы». Большинство других типов не представляют широкого интереса.

5.4.3. Только Linux: указание файлового времени повышенной точности

Ядра Linux 2.6 и более поздние предоставляют в struct stat три дополнительных поля. Они предусматривают точность файлового времени до наносекунд:

st_atime_nsec  Наносекундная компонента времени доступа к файлу.

st_mtime_nsec  Наносекундная компонента времени изменения файла

st_ctime_nsec  Наносекундная компонента времени изменения служебных данных файла.

Некоторые другие системы также предоставляют такие поля с повышенной точностью времени, но имена соответствующих членов структуры struct stat не стандартизованы, что затрудняет написание переносимого кода, использующего эти времена. (Связанные с этим расширенные системные вызовы см. в разделе 14.3.2 «Файловое время в микросекундах: utimes()».)

5.4.4. Определение типа файла

Вспомните, что в поле st_mode закодированы как тип файла, так и права доступа к нему. <sys/stat.h> определяет ряд макросов, которые определяют тип файла. В частности, эти макросы возвращают true или false при использовании с полем st_mode. У каждого описанного ранее типа файла есть свой макрос. Предположим, выполняется следующий код:

struct stat stbuf;

char filename[PATH_МАХ]; /* PATH_MAX из <limits.h> */

/* ... поместить имя файла в filename ... */

if (stat(filename, &stbuf) < 0) {

 /* обработать ошибку */

}

Когда система заполнила stbuf, можно вызывать следующие макросы, причем в качестве аргумента передается stbuf.st_mode:

S_ISREG(stbuf.st_mode)

Возвращает true, если filename является обычным файлом.

S_ISDIR(stbuf.st_mode)

Возвращает true, если filename является каталогом.

S_ISCHR(stbuf.st_mode)

Возвращает true, если filename является символьным устройством. Устройства вскоре будут обсуждены более подробно.

S_ISBLK(stbuf.st_mode)

Возвращает true, если filename является блочным устройством.

S_ISFIFO(stbuf.st_mode)

Возвращает true, если filename является FIFO.

S_ISLNK(stbuf.st_mode)

Возвращает true, если filename является символической ссылкой. (Это может никогда не вернуть true, если вместо lstat() использовались stat() или fstat().)

S_ISSOCK(stbuf.st_mode)

Возвращает true, если filename является сокетом.

ЗАМЕЧАНИЕ. В GNU/Linux эти макросы возвращают 1 для true и 0 для false. Однако, на других системах возможно, что они будут возвращать для true вместо 1 произвольное неотрицательное число. (POSIX определяет лишь ненулевое значение в противоположность нулевому). Поэтому всегда следует использовать эти макросы как автономные тесты вместо проверки возвращаемого значения.

/* Корректное использование */

if (S_ISREG(stbuf.st_mode)) ...

/* Heкорректное использование */

if (S_ISREG(stbuf.st_mode) ==1) ...

Наряду с макросами <sys/stat.h> предоставляет два набора битовых масок. Один набор для проверки прав доступа, а другой - для проверки типа файла. Мы видели маски прав доступа в разделе 4.6 «Создание файлов», когда обсуждали тип mode_t и значения для open() и creat(). Битовые маски, их числовые значения для GNU/Linux и смысл приведены в табл. 5.2.


Таблица 5.2. Битовые маски POSIX для типов файлов и прав доступа в <sys/stat.h>

Маска Значение Комментарий
S_IFMT 0170000 Маска для битовых полей типа файла
S_IFSOCK 0140000 Сокет.
S_IFLNK 0120000 Символическая ссылка
S_IFREG 0100000 Обычный файл.
S_IFBLK 0060000 Блочное устройство.
S_IFDIR 0040000 Каталог.
S_IFCHR 0020000 Символьное устройство.
S_IFIFO 0010000 FIFO.
S_ISUID 0004000 Бит setuid.
S_ISGID 0002000 Бит setgid
S_ISVTX 0001000 «Липкий» (sticky) бит.
S_IRWXU 0000700 Маска для прав доступа владельца.
S_IRUSR 0000400 Доступ на чтение для владельца.
S_IWUSR 0000200 Доступ на запись для владельца.
S_IXUSR 0000100 Доступ на исполнение для владельца.
S_IRWXG 0000070 Маска для прав доступа группы.
S_IRGRP 0000040 Доступ на чтение для группы.
S_IWGRP 0000020 Доступ на запись для группы.
S_IXGRP 0000010 Доступ на исполнение для группы.
S_IRWXO 0000007 Маска для прав доступа остальных.
S_IROTH 0000004 Доступ на чтение для остальных.
S_IWOTH 0000002 Доступ на запись для остальных.
S_IXOTH 0000001 Доступ на исполнение для остальных.
Некоторые из этих масок служат цели изолирования различных наборов битов, закодированных в поле st_mode:

• S_IFMT представляет биты 12–15, которыми закодированы различные типы файлов.

• S_IRWXU представляет биты 6–8, являющиеся правами доступа владельца (на чтение, запись, исполнение для User).

• S_IRWXG представляет биты 3–5, являющиеся правами доступа группы (на чтение, запись, исполнение для Group).

• S_IRWXO представляет биты 0–2, являющиеся правами доступа для «остальных» (на чтение, запись, исполнение для Other).

Биты прав доступа и типа файла графически изображены на рис. 5.3.

Рис. 5.3. Биты прав доступа и типа файлов

Маски типов файлов стандартизованы главным образом для совместимости со старым кодом; они не должны использоваться непосредственно, поскольку такой код менее читаем, чем соответствующие макросы. Случается, что макрос реализован с использованием масок: довольно логично, но это не подходит для кода уровня пользователя.

Стандарт POSIX явным образом констатирует; что в будущем не будут стандартизированы новые битовые маски и что тесты для любых дополнительных разновидностей типов файлов, которые могут быть добавлены, будут доступны лишь в виде макросов S_ISxxx().

5.4.4.1. Сведения об устройстве

Стандарт POSIX не определяет значение типа dev_t, поскольку предполагалось его использование на не-Unix системах также, как на Unix-системах. Однако стоит знать, что находится в dev_t.

Когда истинно S_ISBLK(sbuf.st_mode) или S_ISCHR(sbuf.st_mode), сведения об устройстве находятся в поле sbuf.st_rdev. В противном случае это поле не содержит никакой полезной информации.

Традиционно файлы устройств Unix кодируют старший и младший номера устройства в значении dev_t. По старшему номеру различают тип устройства, такой, как «дисковый привод» или «ленточный привод». Старшие номера различают также разные типы устройств, такие, как диск SCSI в противоположность диску IDE. Младшие номера различают устройства данного типа, например, первый диск или второй. Вы можете увидеть эти значения с помощью 'ls -l':

$ ls -l /dev/hda /dev/hda? /* Показать номера для первого жесткого диска */

brw-rw---- 1 root disk 3, 0 Aug 31 2002 /dev/hda

brw-rw---- 1 root disk 3, 1 Aug 31 2002 /dev/hda1

brw-rw---- 1 root disk 3, 2 Aug 31 2002 /dev/hda2

brw-rw---- 1 root disk 3, 3 Aug 31 2002 /dev/hda3

brw-rw---- 1 root disk 3, 4 Aug 31 2002 /dev/hda4

brw-rw---- 1 root disk 3, 5 Aug 31 2002 /dev/hda5

brw-rw---- 1 root disk 3, 6 Aug 31 2002 /dev/hda6

brw-rw---- 1 root disk 3, 7 Aug 31 2002 /dev/hda7

brw-rw---- 1 root disk 3, 8 Aug 31 2002 /dev/hda8

brw-rw---- 1 root disk 3, 9 Aug 31 2002 /dev/hda9

$ ls -l /dev/null /* Показать сведения также для /dev/null */

crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null

Вместо размера файла ls отображает старший и младший номера. В случае жесткого диска /dev/hda представляет диск в целом, /dev/hda1, /dev/hda2 и т.д. представляют разделы внутри диска. У них у всех общий старший номер устройства (3), но различные младшие номера устройств.

Обратите внимание, что дисковые устройства являются блочными устройствами, тогда как /dev/null является символьным устройством. Блочные и символьные устройства являются отдельными сущностями; даже если символьное устройство и блочное устройство имеют один и тот же старший номер устройства, они необязательно связаны

Старший и младший номера устройства можно извлечь из значения dev_t с помощью функций major() и minor(), определенных в <sys/sysmacros.h>:

#include <sys/types.h> /* Обычный */

#include <sys/sysmacros.h>


int major(dev_t dev);                /* Старший номер устройства */

int minor(dev_t dev);                /* Младший номер устройства */

dev_t makedev(int major, int minor); /* Создать значение dev_t */

(Некоторые системы реализуют их в виде макросов.)

Функция makedev() идет другим путем; она принимает отдельные значения старшего и младшего номеров и кодирует их в значении dev_t. В других отношениях ее использование выходит за рамки данной книги; патологически любопытные должны посмотреть mknod(2).

Следующая программа, ch05-devnum.c, показывает, как использовать системный вызов stat(), макросы проверки типа файла и, наконец, макросы major() и minor().

/* ch05-devnum.c --- Демонстрация stat(), major(), minor(). */

#include <stdio.h>

#include <errno.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/sysmacros.h>


int main(int argc, char **argv) {

 struct stat sbuf;

 char *devtype;

 if (argc != 2) {

  fprintf(stderr, "usage: %s path\n", argv[0]);

  exit(1);

 }

 if (stat(argv[1], &sbuf) < 0) {

  fprintf(stderr, "%s: stat: %s\n", argv[1], strerror(errno));

  exit(1);

 }

 if (S_ISCHR(sbuf.st_mode))

  devtype = "char";

 else if (S_ISBLK(sbuf.st_mode))

  devtype = "block";

 else {

  fprintf(stderr, "%s is not a block or character device\n",

   argv[1]);

  exit(1);

 }

 printf("%s: major: %d, minor: %d\n", devtype,

  major(sbuf.st_rdev), minor(sbuf.st_rdev));

 exit(0);

}

Вот что происходит при запуске программы:

$ ch05-devnum /tmp /* Попробовать не устройство */

/tmp is not a block or character device

$ ch05-devnum /dev/null /* Символьное устройство */

char: major: 1, minor: 3

$ ch05-devnum /dev/hda2 /* Блочное устройство */

block: major: 3, minor: 2

К счастью, вывод согласуется с выводом ls, давая нам уверенность[59], что мы в самом деле написали правильный код.

Воспроизведение вывода ls замечательно и хорошо, но действительно ли это полезно? Ответ — да. Любое приложение, работающее с иерархиями файлов, должно быть способно различать различные типы файлов. Подумайте об архиваторе, таком как tar или cpio. Было бы пагубно, если бы такая программа рассматривала файл дискового устройства как обычный файл, пытаясь прочесть его и сохранить его содержимое в архиве! Или подумайте о find, которая может выполнять произвольные действия, основываясь на типе и других атрибутах файлов, с которыми она сталкивается, (find является сложной программой; посмотрите find(1), если вы с ней не знакомы.) Или даже нечто простое, как пакет, оценивающий свободное дисковое пространство, тоже должно отличать обычные файлы от всего остального.

5.4.4.2. Возвращаясь к V7 cat

В разделе 4.4.4 «Пример: Unix cat» мы обещали вернуться к программе V7 cat, чтобы посмотреть, как она использует системный вызов stat(). Первая группа строк, использовавшая ее, была такой:

31 fstat(fileno(stdout), &statb);

32 statb.st_mode &= S_IFMT;

33 if (statb.st_mode != S_IFCHR && statb.st_mode != S_IFBLK) {

34  dev = statb.st_dev;

35  ino = statb.st_ino;

36 }

Этот код теперь должен иметь смысл. В строке 31 вызывается fstat() для стандартного вывода, чтобы заполнить структуру statb. Строка 32 отбрасывает всю информацию в statb.st_mode за исключением типа файла, используя логическое AND с маской S_IFMT. Строка 33 проверяет, что используемый для стандартного вывода файл не является файлом устройства. В таком случае программа сохраняет номера устройства и индекса в dev и ino. Эти значения затем проверяются для каждого входного файла в строках 50–56.

50 fstat(fileno(fi), &statb);

51 if (statb.st_dev == dev && statb.st_ino == ino) {

52  fprintf(stderr, "cat: input %s is output\n",

53   ffig ? "-" : *argv);

54  fclose(fi);

55  continue;

56 }

Если значения st_dev и st_ino входного файла совпадают с соответствующими значениями выходного файла, cat выдает сообщение и продолжает со следующего файла, указанного в командной строке.

Проверка сделана безусловно, хотя dev и ino устанавливаются, лишь если вывод не является файлом устройства. Это срабатывает нормально из-за того, как эти переменные объявлены:

int dev, ino = -1;

Поскольку ino инициализирован значением (-1), ни один действительный номер индекса не будет ему соответствовать[60]. То, что dev не инициализирован так, является небрежным, но не представляет проблемы, поскольку тест в строке 51 требует, чтобы были равными значения как устройства, так и индекса. (Хороший компилятор выдаст предупреждение, что dev используется без инициализации: 'gcc -Wall' сделает это.)

Обратите также внимание, что ни один вызов fstat() не проверяется на ошибки. Это также небрежность, хотя не такая большая, маловероятно, что fstat() завершится неудачей с действительным дескриптором файла

Проверка того, что входной файл не равен выходному файлу, осуществляется лишь для файлов, не являющихся устройствами. Это дает возможность использовать cat для копирования ввода из файлов устройств в самих себя, как в случае с терминалами:

$ tty /* Вывести имя устройства текущего терминала */

/dev/pts/3

$ cat /dev/pts/3 > /dev/pts/3 /* Копировать ввод от клавиатуры на экран */

this is a line of text /* Набираемое в строке */

this is a line of text /* cat это повторяет */

5.4.5. Работа с символическими ссылками

В общем, символические ссылки ведут себя подобно прямым ссылкам; файловые операции, такие, как open() и stat(), применяются к указываемому файлу вместо самой символической ссылки. Однако, бывают моменты, когда в самом деле необходимо работать с символической ссылкой вместо файла, на которую она указывает.

По этой причине существует системный вызов lstat(). Он действует точно также, как stat(), но если проверяемый файл окажется символической ссылкой, возвращаемые сведения относятся к символической ссылке, а не к указываемому файлу. А именно:

• S_ISLNK(sbuf.st_mode) будет true.

• sbuf.st_size содержит число байтов в имени указываемого файла.

Мы уже видели, что системный вызов symlink() создает символическую ссылку. Но если дана существующая символическая ссылка, как можно получить имя файла, на которую она указывает? (Очевидно, ls может получить это имя; поэтому мы должны быть способны это сделать.)

Открывание ссылки с помощью open() для чтения ее с использованием read() не будет работать, open() следует по ссылке на указываемый файл. Таким образом, символические ссылки сделали необходимым дополнительный системный вызов, который называется readlink():

#include <unistd.h> /* POSIX */


int readlink(const char *path, char *buf, size_t bufsiz);

readlink() помещает содержимое символической ссылки, на имя которой указывает path, в буфер, на который указывает buf. Копируется не более bufsiz символов. Возвращаемое значение равно числу символов, помещенных в buf, либо -1, если возникла ошибка, readlink() не вставляет завершающий нулевой байт.

Обратите внимание, что если буфер, переданный readlink(), слишком маленький, информация будет потеряна; полное имя указываемого файла будет недоступно. Чтобы использовать readlink() должным образом, вы должны делать следующее:

1. Используйте lstat(), чтобы убедиться, что это символическая ссылка.

2. Убедитесь, что ваш буфер для содержимого символической ссылки составляет по крайней мере 'sbuf.st_size + 1' байтов; '+ 1' нужно для завершающего нулевого байта, чтобы сделать буфер годной к употреблению строкой С.

3. Вызовите readlink(). Не мешает проверить, что возвращенное значение равно sbuf.st_size.

4. Добавьте '\0' к байту после содержимого ссылки, чтобы превратить его в строку С. Код для всего этого мог бы выглядеть примерно так:

/* Проверка ошибок для краткости опущена */

int count;

char linkfile[PATH_MAX], realfile[PATH_MAX]; /* PATH_MAX в <limits.h> */

strut stat sbuf;

/* ...поместить в linkfile путь к нужной символической ссылке... */

lstat(linkfile, &sbuf); /* Получить сведения от stat */

if (!S_ISLNK(sbuf.st_mode)) /* Проверить, что это ссылка */

 /* не символическая ссылка, обработать это */

if (sbuf.st_size + 1 > PATH_МАХ) /* Проверить размер буфера */

 /* обработать проблемы с размером буфера */

count = readlink(linkfile, realfile, PATH_MAX);

/* Прочесть ссылку */

if (count != sbuf.st_size)

 /* происходит что-то странное, обработать это */

realfile(count) = '\0'; /* Составить строку С */

Данный пример для простоты представления использует буферы фиксированного размера. Реальный код мог бы использовать для выделения буфера нужного размера malloc(), поскольку массивы фиксированного размера могли бы оказаться слишком маленькими. Файл lib/xreadlink.c в GNU Coreutils делает именно это. Он читает содержимое символической ссылки в память, выделенную malloc(). Мы покажем здесь саму функцию, большая часть файла представляет собой стереотипные определения. Номера строк относятся к началу файла:

55 /* Вызвать readlink для получения значения ссылки FILENAME.

56 Вернуть указатель на завершенную NUL строку в выделенной malloc памяти.

57 При ошибке readlink вернуть NULL (использовать errno для диагноза).

58 При ошибке realloc или если значение ссылки больше SIZE_MAX,

59 выдать диагностику и выйти. */

60

61 char*

62 xreadlink(char const* filename)

63 {

64  /* Начальный размер буфера для ссылки. Степень 2 обнаруживает

65     арифметическое переполнение раньше, но не рекомендуется. */

66  size_t buf_size = 128;

67

68  while(1)

69  {

70   char *buffer = xmalloc(buf_size);

71   ssize_t link_length = readlink(filename, buffer, buf_size);

72

73   if (link_length < 0)

74   {

75    int saved_errno = errno;

76    free(buffer);

77    errno = saved_errno;

78    return NULL;

79   }

80

81   if ((size_t)link_length < buf_size)

82   {

83    buffer[link_length] = 0;

84    return buffer;

85   }

86

87   free(buffer);

88   buf_size *= 2;

89   if (SSIZE_MAX < buf_size || (SIZE_MAX / 2 < SSIZE_MAX && buf_size == 0))

90    xalloc_die();

91  }

92 }

Тело функции состоит из бесконечного цикла (строки 68–91), разрываемого в строке 84, которая возвращает выделенный буфер. Цикл начинается выделением первоначального буфера (строка 70) и чтения ссылки (строка 71). Строки 73–79 обрабатывают случай ошибки, сохраняя и восстанавливая errno таким образом, что она может корректно использоваться вызывающим кодом.

Строки 81–85 обрабатывают случай «успеха», при котором размер содержимого ссылки меньше размера буфера. В этом случае добавляется завершающий ноль (строка 83), а затем буфер возвращается, прерывая бесконечный цикл. Это гарантирует, что в буфер помещено все содержимое ссылки, поскольку у readlink() нет возможности сообщить о «недостаточном размере буфера».

Строки 87–88 освобождают буфер и удваивают размер буфера для следующей попытки в начале цикла. Строки 89–90 обрабатывают случай, при котором размер ссылки слишком велик: buf_size больше, чем SSIZE_MAX, или SSIZE_MAX больше, чем значение, которое может быть представлено в знаковом целом того же размера, который использовался для хранения SIZE_MAX, и buf_size обернулся в ноль. (Это маловероятные условия, но странные вещи все же случаются.) Если одно из этих условий верно, программа завершается с сообщением об ошибке. В противном случае функция возвращается в начало цикла, чтобы сделать еще одну попытку выделить буфер и прочесть ссылку.

Некоторое дополнительное разъяснение: условие 'SIZE_MAX / 2 < SSIZE_MAX' верно лишь на системах, в которых 'SIZE_MAX < 2 * SSIZE_MAX'; мы не знаем таких, но лишь на таких системах buf_size может обернуться в ноль. Поскольку на практике это условие не может быть истинным, компилятор может оптимизировать все выражение, включив следующую проверку 'buf_size == 0'. После прочтения этого кода вы можете спросить: «Почему не использовать lstat() для получения размера символической ссылки, не выделить буфер нужного размера с помощью malloc(), и все?» На это есть несколько причин.[61]

• lstat() является системным вызовом — лучше избежать накладных расходов по его вызову, поскольку содержимое большинства символических ссылок поместится в первоначальный размер буфера в 128.

• Вызов lstat() создает условие состязания: ссылка может измениться между исполнением lstat() и readlink(), в любом случае вынуждая повторение.

• Некоторые системы не заполняют должным образом член st_size для символической ссылки. (Печально, но верно.) Сходным образом, как мы увидим в разделе 8.4.2 «Получение текущего каталога: getcwd()», Linux в /proc предоставляет специальные символические ссылки, у которых st_size равен нулю, но для которых readlink() возвращает действительное содержимое.

Наконец, буфер не слишком большой, xreadlink() использует free() и malloc() с большим размером вместо realloc(), чтобы избежать бесполезного копирования, которое делает realloc(). (Поэтому комментарий в строке 58 устарел, поскольку realloc() не используется; это исправлено в версии Coreutils после 5.0.)

5.5. Смена владельца, прав доступа и времени изменения

Несколько других системных вызовов дают вам возможность изменять другие относящиеся к файлу сведения: в частности, владельца и группу файла, права доступа к файлу и времена доступа и изменения файла.

5.5.1. Смена владельца файла: chown(), fchown() и lchown()

Владелец и группа файла изменяются с помощью трех сходных системных вызовов.

#include <sys/types.h> /* POSIX */

#include <unistd.h>


int chown(const char *path, uid_t owner, gid_t group);

int fchown(int fd, uid_t owner, gid_t group);

int lchown(const char *path, uid_t owner, gid_t group);

chown() работает с аргументом имени файла, fchown() работает с открытым файлом, а lchown() работает с символической ссылкой вместо файла, на который эта ссылка указывает. Во всех других отношениях эти три вызова работают идентично, возвращая 0 в случае успеха и -1 при ошибке.

Стоит заметить, что один системный вызов изменяет как владельца, так и группу файла. Чтобы изменить лишь владельца или лишь группу, передайте (-1) в качестве того идентификационного номера, который должен остаться без изменений.

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

Вы могли бы поинтересоваться: «Зачем нужно изменять владельца символической ссылки? Права доступа и владение ей не имеют значения». Но что случится, если пользователь уходит, а все его файлы все еще нужны? Необходима возможность изменения владельца всех файлов этого лица на кого-то еще, включая символические ссылки.

Системы GNU/Linux обычно не позволяют рядовым пользователям (не root) изменять владельца («отдавать») своих файлов. Смена группы на одну из групп пользователя, конечно, разрешена. Ограничение в смене владельцев идет от BSD систем, у которых тоже есть этот запрет. Главная причина в том, что разрешение пользователям отдавать файлы может нарушить дисковый учет. Рассмотрите такой сценарий:

$ mkdir mywork /* Создать каталог */

$ chmod go-rwx mywork /* Установить права доступа drwx------ */

$ cd mywork /* Перейти в него */

$ myprogram > large_data_file /* Создать большой файл */

$ chmod ugo+rw large_data_file /* Установить доступ -rw-rw-rw- */

$ chown otherguy large_data_file /* Передать файл otherguy */

В этом примере large_data_file теперь принадлежит пользователю otherguy. Первоначальный пользователь может продолжать читать и записывать файл из-за его прав доступа. Но дисковое пространство, которое он занимает, будет записано на счет otherguy. Однако, поскольку он находится в каталоге, который принадлежит первому пользователю и к которому otherguy не может получить доступ, otherguy не имеет возможности удалить файл.

Некоторые системы System V разрешают пользователям передавать свои файлы. (При смене владельца соответствующие биты файлов setuid и setgid сбрасываются.) Это может быть особенной проблемой, когда файлы извлекаются из архива .tar или .cpio; извлеченные файлы имеют UID и GID, закодированный в архиве. На таких системах программы tar и cpio имеют опции, предотвращающие это, но важно знать, что поведение chown() действительно отличается на разных системах.

В разделе 6.3 «Имена пользователя и группы» мы увидим, как соотносить имена пользователя и группы с соответствующими числовыми значениями

5.5.2. Изменение прав доступа: chmod() и fchmod()

Изменение прав доступа осуществляется с помощью одного из двух системных вызовов, chmod() и fchmod():

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>


int chmod(const char *path, mode_t mode);

int fchmod(int fildes, mode_t mode);

chmod() работает с аргументом имени файла, a fchmod() работает с открытым файлом. (В POSIX нет вызова lchmod(), поскольку система игнорирует установки прав доступа для символических ссылок. Хотя на некоторых системах такой вызов действительно есть). Как и для большинства других системных вызовов, они возвращают 0 в случае успеха и -1 при ошибке. Права доступа к файлу может изменить лишь владелец файла или root.

Значение mode создается таким же образом, как для open() и creat(), как обсуждалось в разделе 4.6 «Создание файлов». См. также табл. 5.2, в которой перечислены константы прав доступа.

Система не допустит установки бита setgid (S_ISGID), если группа файла не совпадает с ID действующей группы процесса или с одной из его дополнительных групп. (Мы пока не обсуждали подробно эти проблемы; см. раздел 11.1.1 «Реальные и действующие ID».) Разумеется, эта проверка не относится к root или коду, выполняющемуся как root.

5.5.3. Изменение временных отметок: utime()

Структура struct stat содержит три поля типа time_t:

st_atime  Время последнего доступа к файлу (чтение)

st_mtime  Время последнего изменения файла (запись).

st_ctime  Время последнего изменения индекса файла (например, переименования)

Значение time_t представляет время в «секундах с начала эпохи». Эпоха является Началом Времени для компьютерных систем GNU/Linux и Unix используют в качестве начала Эпохи полночь 1 января 1970 г по универсальному скоординированному времени (UTC).[62] Системы Microsoft Windows используют в качестве начала Эпохи полночь 1 января 1980 г. (очевидно, местное время).

Значения time_t иногда называют временными отметками (timestamps). В разделе 6.1 «Время и даты» мы рассмотрим, как получаются эти данные и как они используются. Пока достаточно знать, чем является значение time_t и то, что оно представляет секунды с начала Эпохи.

Системный вызов utime() позволяет изменять отметки времени доступа к файлу и его изменения:

#include <sys/types.h> /* POSIX */

#include <utime.h>


int utime(const char *filename, struct utimbuf *buf);

Структура utimbuf выглядит следующим образом:

struct utimbuf {

 time_t actime;  /* время доступа */

 time_t modtime; /* время изменения */

};

При успешном вызове возвращается 0, в противном случае возвращается -1. Если buf равен NULL, система устанавливает время доступа и время изменения равным текущему времени.

Чтобы изменить только одну временную отметку, используйте оригинальное значение из struct stat. Например.

/* Для краткости проверка ошибок опущена */

struct stat sbuf;

struct utimbuf ut;

time_t now;


time(&now); /* Получить текущее время дня, см. след. главу */

stat("/some/file", &sbuf); /* Заполнить sbuf */

ut.actime = sbuf.st_atime; /* Время доступа без изменений */

ut.modtime = now - (24 * 60 * 60);

 /* Установить modtime на 24 часа позже */

utime("/some/file", &ut); /* Установить значения */

Вы можете спросить себя: «Почему может понадобиться кому-нибудь изменять времена доступа и изменения файла?» Хороший вопрос.

Чтобы на него ответить, рассмотрите случай программы, создающей дублирующие архивы, такой, как tar или cpio. Эти программы должны прочесть содержание файла, чтобы заархивировать его. Чтение файла, конечно, изменяет время доступа к файлу.

Однако, этот файл, возможно, не читался человеком в течение 10 лет. Некто, набрав 'ls -lu', что отображает время доступа (вместо времени изменения по умолчанию), увидел бы, что последний раз данный файл просматривали 10 лет назад. Поэтому программа архивации должна сохранить оригинальные значения времени доступа и изменения, прочесть файл для архивации, а затем восстановить первоначальное время с помощью utime().

Аналогичным образом, рассмотрите случай архивирующей программы, восстанавливающей файл из архива. В архиве хранятся первоначальные значения времени доступа и изменения. Однако, когда файл извлечен из архива во вновь созданную копию на диске, новый файл имеет текущие дату и время для значений времени доступа и изменения.

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

ЗАМЕЧАНИЕ. В новом коде вы можете захотеть использовать вызов utimes() (обратите внимание на s в имени), который описан далее в книге, в разделе 14.3.2 «Файловое время в микросекундах: utimes()»

5.5.3.1. Подделка utime(file, NULL)

Некоторые более старые системы не устанавливают значения времени доступа и изменения равным текущему времени, когда второй аргумент utime() равен NULL. Однако код более высокого уровня (такой, как GNU touch) проще, если он может полагаться на один стандартизованный интерфейс.

Поэтому библиотека GNU Coreutils содержит замещающую функцию для utime(), которая обрабатывает этот случай, которую потом может вызвать код более высокого уровня. Это отражает принцип проектирования «выбор лучшего интерфейса для работы», который мы описали в разделе 1.5 «Возвращаясь к переносимости».

Замещающая функция находится в файле lib/utime.c в дистрибутиве Coreutils Следующий код является версией из Coreutils 5.0. Номера строк относятся к началу файла:

24 #include <sys/types.h>

25

26 #ifdef HAVE_UTIME_H

27 # include <utime.h>

28 #endif

39

30 #include "full-write.h"

31 #include "safe-read.h"

32

33 /* Некоторые системы (даже имеющие <utime.h>) нигде не объявляют

34    эту структуру. */

35 #ifndef HAVE_STRUCT_UTIMBUF

36 struct utimbuf

37 {

38  long actime;

39  long modtime;

40 };

41 #endif

42

43 /* Эмулировать utime(file, NULL) для систем (подобных 4.3BSD),

44    которые не устанавливают в этом случае текущее время для времени

45    доступа и изменения file. Вернуть 0, если успешно, -1 если нет. */

46

47 static int

48 utime_null(const char *file)

49 {

50 #if HAVE_UTIMES_NULL

51  return utimes(file, 0);

52 #else

53  int fd;

54  char c;

55  int status = 0;

56  struct stat sb;

57

58  fd = open(file, O_RDWR);

59  if (fd < 0

60   || fstat(fd, &sb) < 0

61   || safe_read(fd, &c, sizeof c) == SAFE_READ_ERROR

62   || lseek(fd, (off_t)0, SEEK_SET) < 0

63   || full_write(fd, &c, sizeof c) != sizeof с

64 /* Можно сделать - это необходимо на SunOS4.1.3 с некоторой комбинацией

65    заплат, но та система не использует этот код: у нее есть utimes.

66   || fsync(fd) < 0

67    */

68   || (st.st_size == 0 && ftruncate(fd, st.st_size) < 0)

69   || close(fd) < 0)

70   status = -1;

71  return status;

72 #endif

73 }

74

75 int

76 rpl_utime(const char *file, const struct utimbuf *times)

77 {

78  if (times)

79   return utime(file, times);

80

81  return utime_null(file);

82 }

Строки 33–41 определяют структуру struct utimbuf; как сказано в комментарии, некоторые системы не объявляют эту структуру. Работу осуществляет функция utime_null(). Используется системный вызов utimes(), если он доступен (utimes() является сходным, но более развитым системным вызовом, который рассматривается в разделе 14.3.2 «Файловое время в микросекундах: utimes().» Он допускает также в качестве второго аргумента NULL, что означает использование текущего времени.)

В случае, когда время должно обновляться вручную, код осуществляет обновление, прочитав сначала из файла байт, а затем записав его обратно. (Первоначальный touch Unix работал таким способом.) Операции следующие:

1. Открыть файл, строка 58.

2. Вызвать для файла stat(), строка 60.

3. Прочесть один байт, строка 61 Для наших целей safe_read() действует подобно read(); это объясняется в разделе 10.4.4 «Повторно запускаемые системные вызовы»).

4. Переместиться обратно на начало файла с помощью lseek(), строка 62. Это сделано для записи только что прочитанного байта обратно поверх себя.

5. Записать байт обратно, строка 63. full_write() действует подобно write(); это также рассматривается в разделе 10.4.4 «Повторно запускаемые системные вызовы»).

6. Если файл имеет нулевой размер, использовать ftruncate() для установки его размера в ноль (строка 68). Это не изменяет файл, но имеет побочный эффект обновления времени доступа и изменения (ftruncate() была описана в разделе 4 8 «Установка длины файла».)

7. Закрыть файл, строка 69.

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

Функция rpl_utime() (строки 75–82) является «заместителем utime()». Если второй аргумент не равен NULL, она вызывает настоящую utime(). В противном случае она вызывает utime_null().

5.5.4. Использование fchown() и fchmod() для обеспечения безопасности

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

Однако, после открытия файла условие состязания больше не представляет проблему. Программа может использовать stat() с именем файла для получения информации о файле. Если получены сведения, которые ожидались, после открытия файла fstat() может проверить, что файл тот же самый (сравнив поля st_dev и st_ino структур struct stat «до» и «после»).

Когда программа знает, что файлы те же самые, владение или права доступа могут быть изменены с помощью fchown() или fchmod().

Эти системные вызовы, также как lchown(), сравнительно недавние;[63] в старых системах Unix их не было, хотя в современных совместимых с POSIX системах они есть.

Соответствующих функций futime() или lutime() нет. В случае futime() это (очевидно) потому, что временные отметки не являются критическими для безопасности системы в том же отношении, что для владения и прав доступа, lutime() отсутствует потому, что временные отметки неуместны для символических ссылок.

5.6. Резюме

• Иерархия файлов и каталогов, как она видится пользователю, является одним логическим деревом, корень которого находится в /. Оно составлено из одного или более разделов, каждый из которых содержит файловую систему. Внутри файловой системы в индексах хранятся данные о файлах (метаданные), включая размещение блоков данных.

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

• Прямые ссылки создаются с помощью link(), символические ссылки создаются с помощью symlink(), ссылки удаляются с помощью unlink(), а переименовываются файлы (с возможным перемещением в другой каталог) с помощью rename(). Блоки данных файла не освобождаются до тех пор, пока счетчик ссылок не достигнет нуля и не закроется последний открытый дескриптор файла.

• Каталоги создаются с помощью mkdir(), а удаляются с помощью rmdir(); перед удалением каталог должен быть пустым (не оставлено ничего, кроме '.' и '..'). GNU/Linux версия функции ISO С remove() вызывает соответствующие функции unlink() или rmdir().

• Каталоги обрабатываются с помощью функций opendir(), readdir(), rewinddir() и closedir(). struct dirent содержит номер индекса и имя файла. Максимально переносимый код использует в члене d_name только имя файла. Функции BSD telldir() и seekdir() для сохранения и восстановления текущего положения в каталоге широко доступны, но не полностью переносимы, как другие функции работы с каталогами.

• Вспомогательные данные получаются с помощью семейства системных вызовов stat(), структура struct stat содержит всю информацию о файле за исключением имени файла. (В самом деле, поскольку у файла может быть множество имен или он может совсем не иметь ссылок, невозможно сделать имя доступным.)

• Макрос S_ISxxx() в <sys/stat.h> дает возможность определить тип файла. Функции major() и minor() из <sys/sysmacros.h> дают возможность расшифровки значений dev_t, представляющих блочные и символьные устройства.

• Символические ссылки можно проверить, использовав lstat(), а поле st_size структуры struct stat для символической ссылки возвращает число байтов, необходимых для размещения имени указываемого файла. Содержимое символической ссылки читают с помощью readlink(). Нужно позаботиться о том, чтобы размер буфера был правильным и чтобы завершить полученное имя файла нулевым байтом, чтобы можно было его использовать в качестве строки С.

• Несколько разнообразных системных вызовов обновляют другие данные: семейство chown() используется для смены владельца и группы, процедуры chmod() для прав доступа к файлу, a utime() для изменения значений времени доступа и изменения файла.

Упражнения

1. Напишите программу 'const char *fmt_mode(mode_t mode)'. Ввод представляет собой значение mode_t, полученное из поля st_mode структуры struct stat; т.е. оно содержит как биты прав доступа, так и типа файла.

Вывод должен представлять строку в 10 символов, идентичную первому полю вывода 'ls -l'. Другими словами, первый символ обозначает тип файла, а остальные девять — права доступа.

Когда установлены биты S_ISUID и S_IXUSR, используйте s вместо x; если установлен лишь бит I_ISUID, используйте S. То же относится к битам S_ISGID и S_IXGRP. Если установлены оба бита S_ISVTX и S_IXOTH, используйте t; для одного S_ISVTX используйте T.

Для простоты можете использовать статический (static) буфер, содержимое которого перезаписывается при каждом вызове процедуры.

2. Доработайте ch05-catdir.c, чтобы она вызывала stat() для каждого найденного имени файла. Затем выведите номер индекса, результат вызова fmt_mode(), число ссылок и имя файла.

3. Доработайте ch05-catdir.c так, что если файл является символической ссылкой, программа будет также выводить имя указываемого файла.

4. Добавьте такую опцию, что если имя файла является именем подкаталога, программа рекурсивно входит в него и отображает сведения о файлах (и каталогах) этого подкаталога. Необходим лишь один уровень рекурсии.

5. Если вы не работаете на системе GNU/Linux, запустите ch05-trymkdir (см. раздел 5.2 «Создание и удаление каталогов») на своей системе и сравните результаты с приведенными нами.

6. Напишите программу mkdir. Посмотрите свою локальную справочную страницу для mkdir(1) и реализуйте все ее опции.

7. В корневом каталоге, /, как номер устройства, так и номер индекса для '.' и '..' совпадают. Используя эту информацию, напишите программу pwd.

Вначале программа должна найти имя текущего каталога, прочитав содержимое родительского каталога. Затем она должна продолжить собирать сведения о иерархии файловой системы, пока не достигнет корневого каталога.

Отображение имени каталога в обратном порядке, от текущего каталога до корневого, легко. Как будет справляться ваша версия pwd с выводом имени каталога правильным образом, от корневого каталога вниз?

8. Если вы написали pwd, использовав рекурсию, напишите ее снова, использовав итерацию. Если вы использовали итерацию, напишите ее с использованием рекурсии. Что лучше? (Подсказка: рассмотрите очень глубоко вложенные деревья каталогов.)

9. Тщательно исследуйте функцию rpl_utime() (см. раздел 5.5.3.1 «Подделка utime(file, NULL)»). Какой ресурс не восстанавливается, если одна из проверок в середине if не выполняется? (Спасибо Джеффу Колье (Geoff Collyer).)

10. (Трудное) Прочтите страницу справки для chmod(1). Напишите код для анализа аргумента символических опций, который позволяет добавлять, удалять и устанавливать права доступа на основе владельца, группы, других и «всех».

Когда вы решите, что это работает, напишите свою собственную версию chmod, которая применяет назначенные права доступа к каждому файлу или каталогу, указанному в командной строке. Какую функцию вы использовали, chmod() — или open() и fchmod() — и почему?

Глава 6 Общие библиотечные интерфейсы — часть 1

В главе 5 «Каталоги и служебные данные файлов» мы видели, что непосредственное чтение каталога возвращает имена файлов в том порядке, в каком они хранятся в каталоге. Мы также видели, что struct stat содержит всю информацию о файле за исключением его имени. Однако, некоторые компоненты этой структуры не могут использоваться непосредственно; они являются просто числовыми значениями.

В данной главе представлена оставшаяся часть API, необходимая для полного использования значений компонентов struct stat. Мы по порядку рассматриваем следующие темы: значения time_t для представления времени и функций форматирования времени; функции сортировки и поиска (для сортировки имен файлов или других данных); типы uid_t и gid_t для представления пользователей, групп и функций, которые сопоставляют их с соответствующими именами пользователей и групп; и наконец, функцию для проверки того, что дескриптор файла представляет терминал.

6.1. Времена и даты

Значения времени хранятся в типе, который известен как time_t. Стандарт ISO С гарантирует, что это числовой тип, но во всем остальном никак не указывает, чем именно он является (целым или с плавающей точкой), как и не указывает степень точности хранящихся в нем значений.

На системах GNU/Linux и Unix значения time_t представляют «секунды с начала Эпохи». Эпоха представляет собой начало записываемого времени, которое относится к полночи 1 января 1970 г. по UTC. На большинстве систем time_t является long int С. Для 32-разрядных систем это означает, что time_t переполнится 19 января 2038 г. К тому времени, мы надеемся, тип time_t будет переопределен как по меньшей мере 64-разрядное значение.

Для получения текущего времени, вычисления разницы между двумя значениями time_t, преобразования значений time_t в более удобное представление и форматирования обоих представлений в виде символьных строк существуют различные функции. Вдобавок, представление даты и времени можно преобразовать обратно в time_t, доступна также ограниченная информация по часовым поясам.

Отдельный набор функций предоставляет доступ к текущему времени с разрешением, большим чем одна секунда. Функции работают с предоставлением двух различных значений, времени в виде секунд с начала Эпохи и числа микросекунд в текущей секунде. Эти функции описаны далее в разделе 14.3.1 «Время в микросекундах: gettimeofday()».

6.1.1. Получение текущего времени: time() и difftime()

Системный вызов time() получает текущие дату и время; difftime() вычисляет разницу между двумя значениями time_t:

#include <time.h> /* ISO С */


time_t time(time_t *t);

double difftime(time_t time1, time_t time0);

time() возвращает текущее время. Если параметр t не равен NULL, переменная, на которую указывает t, также заполняется значением текущего времени. Функция возвращает (time_t)(-1), если была ошибка, устанавливая errno.

Хотя ISO С не указывает, чем является значение time_t, POSIX определяет, что оно представляет время в секундах. Поэтому это предположение является обычным и переносимым. Например, чтобы посмотреть, что значение времени представляет отметку в прошлом шесть месяцев назад или позже, можно использовать код, подобный этому:

/* Для краткости проверка ошибок опущена */

time_t now, then, some_time;

time(&now); /* Получить текущее время */

then = now - (6L * 31 * 24 * 60 * 60); /* Примерно 6 месяцев назад */

/* ...установить какое-нибудь время, например, через stat()... */

if (some_time < then)

 /* более 6 месяцев назад */

else

 /* менее 6 месяцев назад */

Однако, поскольку переносимый код может потребоваться запустить на не-POSIX системах, существует функция difftime() для вычисления разницы между двумя значениями времени. Тот же самый тест с использованием difftime() можно было бы написать таким способом:

time_t now, some_value;

const double six_months = 6.0 * 31 * 24 * 60 * 60;

time(&now); /* Получить текущее время */

/* ...установить какое-нибудь время, например, через stat()... */

if (difftime(now, some_time) >= six_months)

 /* более 6 месяцев назад */

else

 /* менее 6 месяцев назад */

Возвращаемым типом difftime() является double, поскольку time_t может также содержать доли секунд. На системах POSIX он всегда представляет целые секунды.

В обоих предыдущих примерах обратите внимание на использование типизированных констант, чтобы форсировать выполнение вычислений с нужным математическим типом: 6L в первом случае для целых long, 6.0 во втором случае для чисел с плавающей точкой

6.1.2. Разложение времени: gmtime() и localtime()

На практике форма представления даты и времени в виде «секунд с начала эпохи» не является очень удобной, кроме очень простых сравнений. Самостоятельное вычисление компонентов времени, таких, как месяц, день, год и т.д., подвержено ошибкам, поскольку необходимо принять во внимание местный часовой пояс (возможно, с учетом перехода на летнее время), правильно вычислить високосные годы и пр. К счастью, две стандартные процедуры делают за вас эту работу:

#include <time.h> /* ISO С */


struct tm *gmtime(const time_t *timep);

struct tm *localtime(const time_t *timep);

gmtime() возвращает указатель на struct tm, которая представляет время UTC. localtime() возвращает указатель на struct tm, представляющий местное время, т.е. в расчет берутся текущий часовой пояс и переход на летнее время. На самом деле это «время для настенных часов», дата и время, которые были бы отображены на настенных или ручных часах. (Как это работает, обсуждается далее в разделе 6.1.5 «Получение сведений о часовом поясе».)

Обе функции возвращают указатель на struct tm, которая выглядит следующим образом:

struct tm {

 int tm_sec;   /* секунды */

 int tm_min;   /* минуты */

 int tm_hour;  /* часы */

 int tm_mday;  /* день месяца */

 int tm_mon;   /* месяц */

 int tm_year;  /* год */

 int tm_wday;  /* день недели */

 int tm_yday;  /* день в году */

 int tm_isdst; /* летнее время */

};

struct tm называют разложенным временем (broken-down time), поскольку значение time_t «разложено» на свои составные части. Составные части, их диапазоны и значения показаны в табл. 6.1.


Таблица 6.1. Поля структуры tm

Член Диапазон Значение
tm_sec 0–60 Секунда минуты. Секунда 60 предусматривает пропущенные (leap) секунды. (В C89 был диапазон 0–61.)
tm_min 0–59 Минута часа.
tm_hour 0–23 Час дня
tm_mday 1–31 День месяца
tm_mon 0–11 Месяц года
tm_year 0–N Год, начиная с 1900 г.
tm_wday 0–6 День недели, воскресенье = 0
tm_yday 0–365 День года, 1 января = 0.
tm_isdst <0, 0, >0 Флаг летнего времени.
Стандарт ISO С представляет большинство этих значений как «x после y». Например, tm_sec является числом «секунд после минуты», tm_mon «месяцев после января», tm_wday «дней недели после воскресенья» и т.д. Это помогает понять, почему все значения начинаются с 0. (Единственным исключением, достаточно логичным, является tm_mday, день месяца, имеющий диапазон 1–31.) Конечно, отсчет их с нуля также практичен; поскольку массивы С отсчитываются с нуля, использование этих значений в качестве индексов тривиально:

static const char *const days[] = { /* Массив имен дней */

 "Sunday", "Monday", "Tuesday", "Wednesday",

 "Thursday", "Friday", "Saturday",

};

time_t now;

struct tm *curtime;


time(&now); /* Получить текущее время */

curtime = gmtime(&now); /* Разложить его */

printf("Day of the week: %s\n", days[curtime->tm_wday]);

 /* Проиндексировать и вывести */

Как gmtime(), так и localtime() возвращают указатель на struct tm. Указатель указывает на static struct tm, содержащуюся в каждой процедуре, и похоже, что эти структуры struct tm переписываются каждый раз, когда вызываются процедуры. Поэтому хорошая мысль сделать копию возвращенной struct. Возвращаясь к предыдущему примеру.

static const char *const days[] = { /* Как ранее */ };

time_t now;

struct tm curtime; /* Структура, а не указатель */

time(&now); /* Получить текущее время */

curtime = *gmtime(&now); /* Разложить его и скопировать данные */

printf("Day of the week: %s\n", days[curtime.tm_wday]);

 /* Проиндексировать и напечатать, использовать . , а не -> */

Поле tm_isdst указывает, действует ли в настоящий момент летнее время (DST) Значение 0 означает, что DST не действует, положительное значение означает, что действует, а отрицательное значение — что информация о DST недоступна. (Стандарт С намеренно неконкретен, указывая лишь нулевое, положительное и отрицательное значения; это дает возможность большей свободы при реализации.)

6.1.3. Форматирование даты и времени

Примеры в предыдущем разделе показали, как поля в struct tm могли бы быть использованы в качестве индексов символьных строк для вывода информативных значений даты и времени. Хотя можно было бы написать собственный код, использующий такие массивы для форматирования даты и времени, стандартные процедуры облегчают работу

6.1.3.1. Простое форматирование времени: asctime() и ctime()

Две первые стандартные процедуры, перечисленные ниже, выводят данные в фиксированном формате:

#include <time.h> /* ISO С */


char *asctime(const struct tm *tm);

char *ctime(const time_t *timep);

Как и в случае с gmtime() и localtime(), asctime() и ctime() возвращают указатели на статические буфера, которые могут быть перезаписаны после каждого вызова. Более того, эти две процедуры возвращают строки в одном и том же формате. Они отличаются лишь видом принимаемых аргументов, asctime() и ctime() должны использоваться тогда, когда все, что вам нужно, это простые сведения о дате и времени.

#include <stdio.h>

#include <time.h>


int main(void) {

 time_t now;

 time(&now);

 printf("%s", ctime(& now));

}

После запуска эта программа выводит результат в виде: 'Thu May 22 15:44:21 2003'. Завершающий символ конца строки включен в результат. Точнее, возвращаемое значение указывает на массив из 26 символов, как показано на рис. 6.1.

Рис. 6.1. Возвращаемая функциями ctime() и asctime() строка

Значительная часть старого кода Unix полагается на тот факт, что значения в возвращенной строке имеют фиксированную позицию. При использовании этих функций помните, что они включают завершающий символ конца строки. Поэтому наш небольшой пример программы использует для printf() простую форматирующую строку "%s", а не "%s\n", как можно было бы ожидать.

ctime() устраняет необходимость шага вызова localtime(); в сущности, это эквивалентно

time_t now;

char *curtime;

time(&now);

curtime = asctime(localtime(&now));

6.1.3.2. Сложное форматирование времени: strftime()

Хотя часто достаточно использования asctime() и ctime(), у них есть также и ограничения:

• Формат вывода фиксирован. Нет способа изменить порядок элементов.

• В вывод не включаются сведения о часовом поясе.

• В выводе используются сокращенные названия месяца и дня.

• В выводе используются английские названия месяцев и дней.

По этим причинам C89 ввело стандартную библиотечную процедуру strftime():

#include <time.h> /* ISO С */


size_t strftime(char *s, size_t max, const char *format,

 const struct tm *tm);

strftime() сходна с sprintf(). Ее аргументы следующие:

char *s

Буфер для форматированной строки.

size_t max

Размер буфера.

const char *format

Форматирующая строка.

const struct tm *tm

Указатель на struct tm, представляющий разложенное время, которое надо отформатировать.

Форматирующая строка содержит символы букв, смешанные о описателями преобразования, указывающими, что должно быть помещено в строку, такими, как полное имя дня недели, час в соответствии с 24-часовым или 12-часовым циклом, наличие указателей am или p.m[64], и т.д. (Вскоре будут приведены примеры.)

Если всю строку можно отформатировать с использованием не более max символов, возвращаемое значение представляет собой число символов, помещенных в s, не включая завершающий нулевой байт. В противном случае, возвращаемое значение ноль. В последнем случае содержание s «неопределенно». Следующий простой пример дает представление об использовании strftime():

#include <stdio.h>

#include <time.h>


int main(void) {

 char buf[100];

 time_t now;

 struct tm *curtime;

 time(&now);

 curtime = localtime(&now);

 (void)strftime(buf, sizeof buf,

  "It is now %A, %B %d, %Y, %I:%M %p", curtime);

 printf("%s\n", buf);

 exit(0);

}

После запуска эта программа выводит что-то типа:

It is now Thursday, May 22, 2003, 04:15 PM

В табл. 6.2 предоставлен полный список описателей преобразования, их возможные альтернативные представления и их значения. Вдобавок стандарт C99 добавил к списку дополнительные описатели; новые для C99 описатели помечены символом √.


Таблица 6.2. Описатели преобразования формата strftime()

align = "left" valign = "top" >%j
Описатель C99 Значение
%a Локальное сокращенное название дня недели.
%A Локальное полное название дня недели.
%b Локальное сокращенное название месяца.
%B Локальное полное название месяца.
%c, %Ec Локальное «подходящее» представление даты и времени
%C, %EC Век (00–99)
%d, %Od День месяца (01–31)
%D То же, что %m/%d/%y
%e, %Oe День месяца. Одна цифра дополняется пробелом (1–31).
%F То же, что и %Y-%m-%d (формат даты ISO 8601)
%g Две последние цифры, основанной на неделе года (00–99).
%G Основанный на неделе год ISO 8601
%h То же, что и %b
%H, %OH Час в 24-часовом цикле (00–23)
%I, %OI Час в 12-часовом цикле (01–12)
День года (001–366)
%m, %Om Месяц в виде числа (01–12).
%M, %OM Минута в виде числа (00–59)
%n Символ конца строки ('\n')
%p Локальное обозначение a.m./p.m.
%r Локальное время в 12-часовом цикле
%R Тоже, что и %H:%M
%S, %OS Секунда в виде числа (00–60)
%t Символ табуляции ('\t')
%T То же, что и %H:%M:%S (формат ISO 8601).
%u, %Ou Число дня недели ISO 8601, понедельник = 1 (1–7).
%U, %OU Номер недели, первое воскресенье является первым днем недели 1 (00–53)
%V, %OV Номер недели ISO 8601 (01–53)
%w, %Ow День недели как число, воскресенье = 0 (0–6).
%W, %OW Номер недели, первый понедельник является первым днем недели 1 (00–53)
%x, %Ex Локальное «подходящее» представление даты
%X, %EX Локальное «подходящее» представление времени.
%y, %Ey, %Oy Две последние цифры года (00–99)
%Y, %EY Год как число.
%Z Локальный часовой пояс или отсутствие символов, если сведения о часовом поясе недоступны
%% Простой %
Локаль (locale) является способом описания местной специфики, принимая во внимание такие вещи, как язык, кодировка символов и значения по умолчанию для форматирования дат, времени, денежных сумм и т.д. Мы будем иметь с ними дело в главе 13 «Интернационализация и локализация». Пока достаточно понять, что результаты strftime() для одной и той же форматирующей строки могут быть разными в зависимости от настроек текущей локали.

Версии, начинающиеся с %E и %O, предназначены для «альтернативного представления». В некоторых локалях есть несколько способов представления одних и тех же сведений; эти описатели предоставляют доступ к дополнительным представлениям. Если определенная локаль не поддерживает альтернативного представления, strftime() использует обычную версию.

Многие Unix-версии date дают возможность предоставить в командной строке форматирующую строку, начинающуюся с символа '+'. Затем date форматирует текущие дату и время и выводит в соответствии с форматирующей строкой:

$ date + 'It is now %A, %B %d, %Y, %I:%M %p'

It is now Sunday, May 25, 2003, 06:44 PM

Большинство новых описателей C99 происходит от таких существующих реализаций date Unix. Описатели %n и %t не являются в С абсолютно необходимыми, поскольку символы табуляции и конца строки могут быть помещены в строку непосредственно. Однако в контексте форматирующей строки date для командной строки они имеют больше смысла. Поэтому они также включены в спецификацию strftime().

Стандарт ISO 8601 определяет (среди других вещей), как нумеруются недели в пределах года. В соответствии с этим стандартом недели отсчитываются с понедельника по воскресенье, а понедельник является днем недели 1, а не 0. Если неделя, в которой оказывается 1 января, содержит по крайней мере четыре дня нового года, она считается неделей 1. В противном случае, это последняя неделя предыдущего года с номером 52 или 53. Эти правила используются для вычислений описателей форматов %g, %G и %V. (Хотя ограниченным американцам, таким, как автор, эти правила могут показаться странными, они обычно повсюду используются в Европе.)

Многие из описателей стандартов дают результаты, специфичные для текущей локали. Вдобавок некоторые указывают, что они выдают «подходящее» представление для локали (например, %x). Стандарт C99 определяет значения для локали «С». Эти значения перечислены в табл. 6.3


Таблица 6.3. Значения локали «С» для определенных форматов strftime()

Описатель Значение
Первые три символа .
Один из дней Sunday, Monday, …, Saturday
%b Первые три символа
Один из месяцев January, February, …, December
То же, что и %а %b %е %T %Y
%p AM или PM
%r То же, что и %I:%M:%S %p
%x То же, что и %m/%d/%y
%X То же, что и %T.
%Z Определяется реализацией
Должно быть очевидно, что strftime() предоставляет значительную гибкость и контроль над связанным с датой и временем выводом, во многом таким же образом, как printf() и sprintf(). Более того, strftime() не может переполнить буфер, поскольку она проверяет входной параметр размера, что делает ее более безопасной процедурой, чем sprintf().

В качестве простого примера рассмотрим создание файлов журнала программы, когда каждый час создается новый файл. Имя файла должно включать дату и время создания:

/* Проверка ошибок для краткости опущена */

char fname[PATH_МАХ]; /* PATH_МАХ находится в <limits.h> */

time_t now;

struct tm *tm;

int fd;


time(&now);

tm = localtime(&now);

strftime(fname, sizeof fname, "/var/log/myapp.%Y-%m-%d-%H:%M", tm);

fd = creat(name, 0600);

...

Формат год-месяц-день-час-минута вызывает сортировку файлов в том порядке, в каком они были созданы.

ЗАМЕЧАНИЕ. Некоторые форматы данных более полезны, чем другие. Например, 12-часовое время двусмысленно, также, как чисто числовые форматы дат. (Что означает '9/11'? Это зависит от того, где вы живете) Сходным образом, годы из двух цифр также являются плохой мыслью. Используйте strftime() благоразумно

6.1.4. Преобразование разложенного времени в time_t

Получение от системы значений «секунд с начала Эпохи» просто; именно так даты и времена хранятся в индексах и возвращаются с помощью time() и stat(). Эти значения также легко оценивать на равенство или посредством < и > для простых тестов раньше/позже.

Однако, с датами, введенными людьми, не так легко работать. Например, многие версии команды touch позволяют предусмотреть дату и время, в которое touch должна установить время модификации или доступа к файлу (с помощью utime(), как было описано в разделе 5.5.3 «Изменение отметок времени: utime()»).

Преобразование даты, введенной человеком, в значение time_t трудно: надо принять во внимание високосные годы, учесть часовые пояса и т.д. Поэтому стандарт C89 ввел функцию mktime():

#include <time.h> /* ISO С */


time_t mktime(struct tm *tm);

Для использования mktime() укажите в struct tm соответствующие значения — год, месяц, день и т.д. Если вы знаете, действовало ли для данной даты летнее время, установите соответствующим образом поле tm_isdst: 0 для «нет» и положительное значение для «да». В противном случае, используйте отрицательное значение для «не знаю». Поля tm_wday и tm_yday игнорируются.

mktime() предполагает, что struct tm представляет локальное время, не UTC. Она возвращает значение time_t, представляющее переданные дату и время, или (time_t)(-1), если данные дата/время не могут быть правильно представлены. После успешного возвращения все значения struct tm выверены на попадание в правильные диапазоны, a tm_wday и tm_yday также корректно установлены. Вот простой пример:

1  /* ch06-echodate.c --- демонстрирует mktime(). */

2

3  #include <stdio.h>

4  #include <time.h>

5

6  int main(void)

7  {

8   struct tm tm;

9   time_t then;

10

11  printf("Enter a Date/time as YYYY/MM/DD HH:MM:SS : ");

12  scanf("%d/%d/%d %d:%d:%d",

13   &tm.tm_year, &tm.tm_mon, &tm.tm_mday,

14   &tm.tm_hour, &tm.tm_min, &tm.tm_sec);

15

16  /* Проверка ошибок значений для краткости опущена. */

17  tm.tm_year -= 1900;

18  tm.tm_mon--;

19

20  tm.tm_isdst = -1; /* He знаю о летнем времени */

21

22  then = mktime(&tm);

23

24  printf("Got: %s", ctime(&then));

25  exit(0);

26 }

В строке 11 запрашиваются дата и время, а в строках 12–14 соответствующие значения считываются. (В коде изделия возвращаемые scanf() значения должны проверяться.) Строки 17 и 18 компенсируют различную базу для лет и месяцев соответственно. Строка 20 указывает, что мы не знаем, представляют ли данные дата и время летнее время. Строка 22 вызывает mktime(), а строка 24 выводит результат преобразования. После компилирования и запуска мы видим, что это работает:

$ ch06-echodate

Enter a Date/time as YYYY/MM/DD HH:MM:SS : 2003/5/25 19:07:23

Got: Sun May 25 19:07:23 2003

6.1.5. Получение сведений о часовом поясе

На ранних системах Unix сведения о часовом поясе внедрялись в ядро при компиляции. Правила перехода на летнее время обычно были жестко вшиты в код, что создавало трудности для пользователей вне Соединенных Штатов или в местах внутри Соединенных Штатов, в которых не осуществлялся переход на летнее время.

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

Интерфейс языка С для сведений о часовых поясах развивался в разных версиях Unix, как на System V, так и Berkley, пока, наконец, не был стандартизован POSIX следующим образом.

#include <time.h> /* POSIX */


extern char *tzname[2];

extern long timezone;

extern int daylight;


void tzset(void);

Функция tzset() проверяет переменную окружения TZ для получения сведений о часовом поясе и переходе на летнее время.[65] Если эта переменная не установлена, tzset() использует «определенный в реализации часовой пояс по умолчанию», который скорее всего является часовым поясом машины, на которой вы работаете.

После вызова tzset() сведения о локальном часовом поясе доступны в нескольких переменных:

extern char *tzname[2]

Стандартное имя и имя летнего времени для часового пояса. Например, для областей США в восточном часовом поясе именами часового пояса являются 'EST' (Eastern Standard Time) и 'EDT' (Eastern Daylight Time).

extern long timezone

Разница в секундах между текущим часовым поясом и UTC. Стандарт не определяет, как эта разница работает. На практике отрицательные значения представляют часовые пояса восточнее (перед, или те, которые позже) UTC; положительные значения представляют часовые пояса западнее (за, или те, которые раньше) UTC. Если вы посмотрите на это значение как «насколько изменить местное время, чтобы оно стало равно UTC», тогда знак этого значения имеет смысл.

extern int daylight

Эта переменная равна нулю, если правила перехода на летнее время никогда не должны использоваться для данного часового пояса, и не равны нулю в противном случае.

ЗАМЕЧАНИЕ. Переменная daylight не означает, действует ли в настоящий момент летнее время! Вместо этого она просто констатирует, может ли текущий часовой пояс вообще иметь летнее время.

Стандарт POSIX указывает, что ctime(), localtime(), mktime() и strftime() действуют, «как если бы» они вызывали tzset(). Это означает, что им в действительности не нужно вызывать tzset(), но они должны вести себя, как если бы эта функция была вызвана. (Формулировка призвана дать определенную гибкость при реализации, в то же время гарантируя правильное поведение кода уровня пользователя.)

На практике это означает, что вы сами почти никогда не будете вызывать tzset(). Но если понадобится, эта функция есть.

6.1.5.1. Системы BSD: timezone(), не timezone

Некоторые производные от BSD 4.4 системы вместо переменной POSIX timezone предоставляют функцию timezone():

#include <time.h> /* BSD */

char *timezone(int zone, int dst);

Аргумент zone является числом минут западнее GMT, a dst истинно, если действует летнее время. Возвращаемое значение является строкой, дающей имя указанного часового пояса, или значение, выраженное относительно GMT. Эта функция обеспечивает совместимость с функцией V7 с тем же именем и поведением.

Локальное время: откуда оно известно?
Системы GNU/Linux хранят информацию о часовых поясах в файлах и каталогах в /usr/share/zoneinfo:

$ cd /usr/share/zoneinfo

$ ls -FC

Africa/     Canada/ Factory    Iceland   MST7MDT  Portugal  W-SU

America/    Chile/  GB         Indian/   Mexico/  ROC       WET

Antarctica/ Cuba    GB-Eire    Iran      Mideast/ ROK       Zulu

Arctic/     EET     GMT        Israel    NZ       Singapore iso3166.tab

Asia/       EST     GMT+0      Jamaica   NZ-CHAT  SystemV/  posix/

Atlantic/   EST5EDT GMT-0      Japan     Navajo   Turkey    posixrules

Australia/  Egypt   GMT0       Kwajalein PRC      UCT       right/

Brazil/     Eire    Greenwich  Libya     PST8PDT  US/       zone.tab

CET         Etc/    HST        MET       Pacific/ UTC

CST6CDT     Europe/ Hongkong   MST       Poland   Universal

Когда возможно, этот каталог использует прямые ссылки для предоставления одних и тех же данных с разными именами. Например, файлы EST5EDT и US/Eastern на самом деле одни и те же:

$ ls -il EST5EDT US/Eastern

724350 -rw-r--r-- 5 root root 1267 Sep б 2002 EST5EDT

724350 -rw-r--r-- 5 root root 1267 Sep 6 2002 US/Eastern

Частью установки системы является выбор часового пояса. Надлежащий файл данных часового пояса помещается затем в /etc/localtime:

$ file /etc/localtime

/etc/localtime: timezone data

На нашей системе это автономная копия файла для нашего часового пояса. На других системах это может быть символическая ссылка на файл в /usr/share/zoneinfo. Преимуществом использования отдельной копии является то, что все по-прежнему работает, если /usr не смонтирован.

Переменная окружения TZ, если она установлена, перекрывает значение по умолчанию для часового пояса:

$ date /* Дата и время в часовом поясе по умолчанию

        */

Wed Nov 19 06:44:50 EST 2003

$ export TZ=PST8PDT /* Смена часового пояса на Западное

                       побережье США */

$ date /* Вывести дату и время */

Wed Nov 19 03:45:09 PST 2003

Широкое распространение этой функции делает переносимое использование переменной POSIX timezone трудной. К счастью, мы не видим большой потребности в ней strftime() должно быть достаточно едва ли не для большинства необычных потребностей

6.2. Функции сортировки и поиска

Сортировка и поиск являются двумя фундаментальными операциями, потребность в которых постоянно возникает во многих приложениях Библиотека С предоставляет ряд стандартных интерфейсов для осуществления этих задач.

Все процедуры разделяют общий лейтмотив; данные управляются через указатели void*, а сортировку осуществляют предоставленные пользователем функции. Обратите также внимание, что эти API применяются к данным в памяти. Структуры сортировки и поиска в файлах значительно более сложны и выходят за рамки вводного руководства, подобного данному. (Однако, команда sort хорошо работает для текстовых файлов; см. справочную страницу для sort(1). Сортировка двоичных файлов требует написания специальной программы.)

Поскольку ни один алгоритм не работает одинаково хорошо для всех приложений, имеются несколько различных наборов библиотечных процедур для сопровождения искомых коллекций данных. Данная глава рассматривает лишь один простой интерфейс для поиска. Другой, более развитый интерфейс описан в разделе 14.4 «Расширенный поиск с использованием двоичных деревьев». Более того, мы намеренно не объясняем лежащие в основе алгоритмы, поскольку данная книга об API, а не об алгоритмах и структурах данных. Важно понять, что API можно рассматривать как «черные ящики», выполняющие определенную работу без необходимости понимания подробностей их работы.

6.2.1. Сортировка: qsort()

Сортировка выполняется с помощью qsort():

#include <stdlib.h> /* ISO С */


void qsort(void *base, size_t nmemb, size_t size,

 int (*compare)(const void*, const void*));

Название qsort() происходит от алгоритма машинного поиска Хоара Quicksort (C.A.R. Hoare's Quicksort algorithm), который использовался в первоначальной реализации Unix. (Ничто в стандарте POSIX не требует использования этого алгоритма для qsort(). Реализация GLIBC использует высоко оптимизированную комбинацию Quicksort и Insertion Sort.)

qsort() сортирует массивы произвольных объектов. Она работает, перетасовывая непрозрачные участки памяти из одного места массива в другой и полагаясь на то, что вы, программист, предоставите функцию сравнения, которая позволяет определить относительное расположение одного элемента массива относительно другого. Аргументы следующие:

void *base

Адрес начала массива.

size_t nmemb

Общее число элементов в массиве.

size_t size

Размер каждого элемента массива. Лучший способ получения этого значения — оператор С sizeof.

int (*compare)(const void*, const void*)

Возможно устрашающее объявление указателя функции. Оно говорит, что «compare указывает на функцию, которая принимает два параметра 'const void*' и возвращает int».

Большая часть работы заключается в написании соответствующей функции сравнения. Возвращаемое значение должно имитировать соответствующее значение strcmp(): меньше нуля, если первое значение «меньше» второго, ноль, если они равны, и больше нуля, если первое значение «больше» второго. Именно функция сравнения определяет значения «больше» и «меньше» для всего, что вы сравниваете. Например, для сравнения двух значений double мы могли бы использовать эту функцию:

int dcomp(const void *d1p, const void *d2p) {

 const double *d1, *d2;

 d1 = (const double*)d1p; /* Привести указатели к нужному типу */

 d2 = (const double*)d2p;

 if (*d1 < *d2) /* Сравнить и вернуть нужное значение */

  return -1;

 else if (*d1 > *d2)

  return 1;

 else if (*d1 == *d2)

  return 0;

 else

  return -1; /* NaN сортируется до действительных чисел */

}

Это показывает общий стереотип для функций сравнения: привести тип аргументов от void* к указателям на сравниваемый тип, а затем вернуть результат сравнения.

Для чисел с плавающей точкой простое вычитание, подобное 'return *d1 - *d2', не работает, особенно если одно значение очень маленькое или одно или оба значения являются специальными значениями «не число» или «бесконечность». Поэтому нам приходится осуществлять сравнение вручную, принимая во внимание нечисловое значение (которое даже не равно самому себе!)

6.2.1.1. Пример: сортировка сотрудников

Для более сложных структур требуются более сложные функции. Например, рассмотрите следующую (довольно тривиальную) struct employee:

struct employee {

char lastname[30];

char firstname[30];

long emp_id;

time_t start_date;

};

Мы могли бы написать функцию для сортировки сотрудников по фамилии, имени и идентификационному номеру:

int emp_name_id_compare(const void *e1p, const void *e2p) {

 const struct employee *e1, *e2;

 int last, first;

 e1 = (const struct employee*)e1p; /* Преобразовать указатели */

 e2 = (const struct employee*)e2p;

 if ((last = strcmp(e1->lastname, e2->lastname)) != 0)

  /* Сравнить фамилии */

  return last; /* Фамилии различаются */

 /* фамилии совпадают, сравнить имена */

 if ((first = strcmp(e1->firstname, e2->firstname)) != 0)

  /* Сравнить имена */

  return first; /* Имена различаются */

 /* имена совпадают, сравнить номера ID */

 if (e1->emp_id < e2->emp_id) /* Сравнить ID сотрудника */

  return -1;

 else if (e1->emp_id == e2->emp_id)

  return 0;

 else

  return 1;

}

Логика здесь проста: сначала сравниваются фамилии, затем имена, а затем номера ID, если два имени совпадают. Используя для строк strcmp(), мы автоматически получаем правильное отрицательное/нулевое/положительное значение для возвращения.

При сравнении ID сотрудников нельзя просто использовать вычитание: представьте, что long 64-разрядный, а int 32-разрядный, а два значения отличаются лишь в старших 32 битах (скажем, младшие 32 бита равны нулю). В таком случае вычитание автоматически привело бы к приведению типа к int с отбрасыванием старших 32 битов и возвращением неверного результата.

ЗАМЕЧАНИЕ. Возможно, мы остановились при сравнении имен, в этом случае все сотрудники с совпадающими фамилиями и именами оказались бы сгруппированы, но никак не отсортированы

Это важный момент qsort() не гарантирует стабильной сортировки. Стабильна сортировка, в которой, если два элемента равны на основе значения какого-либо ключа(-ей), они сохраняют свой первоначальный порядок друг относительно друга в конечном отсортированном массиве. Например, рассмотрите трех сотрудников с одинаковыми фамилиями и именами и с номерами 17, 42 и 81. Их порядок в первоначальном массиве. возможно, был 42, 81 и 17 (Что означает, что сотрудник 42 находится по индексу с меньшим значением, чем сотрудник 81, который, в свою очередь, находится по индексу с меньшим значением, чем сотрудник 17). После сортировки порядок может оказаться 81, 42 и 17. Если ото представляет проблему, процедура сравнения должна рассматривать все важные ключевые значения (Наша так и делает.)

Просто используя другую функцию, мы можем отсортировать сотрудников по старшинству:

int emp_seniority_compare(const void *e1p,

 const void *e2p) {

 const struct employee *e1, *e2;

 double diff;

 /* Привести указатели к нужному типу */

 e1 = (const struct employee*)e1p;

 e2 = (const struct employee*)e2p;

 /* Сравнить времена */

 diff = difftime(e1->start_date, e2->start_date);

 if (diff < 0)

  return -1;

 else if (diff > 0)

  return 1;

 else

  return 0;

}

Для максимальной переносимости мы использовали difftime(), которая возвращает разницу в секундах между двумя значениями time_t. Для данного конкретного случая приведение, такое, как

return (int)difftime(e1->start_date, e2->start_date);

должно сработать, поскольку значения time_t находятся в приемлемом диапазоне. Тем не менее, мы вместо этого использовали полный трехсторонний оператор if, просто из предосторожности.

Вот пример файла данных со списком пяти президентов США:

$ cat presdata.txt

/* Фамилия, имя, номер президента, инаугурация */

Bush George 43 980013600

Clinton William 42 727552800

Bush George 41 601322400

Reagan Ronald 40 348861600

Carter James 39 222631200

В ch06-sortemp.c приведена простая программа, которая считывает этот файл в массив struct employee, а затем сортирует его, используя две только что представленные функции сравнения.

1   /* ch06-sortemp.c --- Демонстрирует qsort() с двумя функциями сравнения. */

2

3   #include <stdio.h>

4   #include <stdlib.h>

5   #include <time.h>

6

7   struct employee {

8    char lastname[30];

9    char firstname[30];

10   long emp_id;

11   time_t start_date;

12  };

13

14  /* emp_name_id_compare --- сравнение по имени, затем no ID */

15

16  int emp_name_id_compare(const void *e1p, const void *e2p)

17  {

     /* ...как показано ранее, опущено для экономии места... */

39  }

40

41  /* emp_seniority_compare --- сравнение по старшинству */

42

43  int emp_seniority_compare(const void *e1p, const void *e2p)

44  {

     /* ...как показано ранее, опущено для экономии места... */

58  }

59

60  /* main --- демонстрация сортировки */

61

62  int main(void)

63  {

64   #define NPRES 10

65   struct employee presidents[NPRES];

66   int i, npres;

67   char buf[BUFSIZ];

68

69   /* Очень простой код для чтения данных: */

70   for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, stdin) != NULL;

71    npres++) {

72    sscanf(buf, "%s %s %ld %ld\n",

73     presidents[npres].lastname,

74     presidents[npres].firstname,

75     &presidents[npres].emp_id,

76     &presidents[npres].start_date);

77   }

78

79   /* npres теперь содержит число прочитанных строк. */

80

81   /* Сначала сортировка по имени */

82   qsort(presidents, npres, sizeof(struct employee), emp_name_id_compare);

83

84   /* Вывести результат */

85   printf("Sorted by name:\n");

86   for (i = 0; i < npres; i++)

87    printf("\t%s %s\t%d\t%s",

88     presidents[i].lastname,

89     presidents[i].firstname,

90     presidents[i].emp_id,

91     ctime(&presidents[i].start_date));

92

93   /* Теперь сортировка по старшинству */

94   qsort(presidents, npres, sizeof(struct employee), emp_seniority_compare);

95

96   /* И снова вывести */

97   printf("Sorted by seniority:\n");

98   for (i = 0; i < npres; i++)

99    printf("\t%s %s\t%d\t%s",

100    presidents[i].lastname,

101    presidents!i].firstname,

102    presidents[i].emp_id,

103    ctime(&presidents[i].start_date));

104 }

Строки 70–77 считывают данные. Обратите внимание, что любое использование scanf() требует от входных данных «хорошего поведения». Если, например, какое-нибудь имя содержит более 29 символов, возникает проблема. В данном случае, мы вне опасности, но в коде изделия нужно быть гораздо более осмотрительным.

Строка 82 сортирует данные по имени и по ID сотрудника, а затем строки 84–91 выводят отсортированные данные. Сходным образом строка 94 пересортировывает данные, на этот раз по старшинству, а строки 97–103 выводят результаты. После компилирования и запуска программа выдает следующие результаты:

$ ch06-sortemp < presdata.txt

Sorted by name:

  Bush George 41 Fri Jan 20 13:00:00 1989

  Bush George 43 Sat Jan 20 13:00:00 2001

  Carter James 39 Thu Jan 20 13:00:00 1977

  Clinton William 42 Wed Jan 20 13:00:00 1993

  Reagan Ronald 40 Tue Jan 20 13:00:00 1981 \

Sorted by seniority:

  Carter James 39 Thu Jan 20 13:00:00 1977

  Reagan Ronald 40 Tue Jan 20 13:00:00 1981

  Bush George 41 Fri Jan 20 13:00:00 1989

  Clinton William 42 Wed Jan 20 13:00:00 1993

  Bush George 43 Sat Jan 20 13:00:00 2001

(Мы использовали 1 час пополудни как приблизительное время, когда все президенты начали работать.)[66]

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

Платой за это является дополнительная память для размещения указателей и модификация функций сравнения для дополнительного перенаправления указателей при сравнении структур. Полученной выгодой может стать значительное ускорение работы, поскольку на каждом шаге перемещается лишь четырех- или восьмибайтный указатель вместо большой структуры. (Наша struct employee имеет размер по крайней мере 68 байтов. При обмене четырехбайтных указателей перемещается в 17 раз меньше данных, чем при обмене структур.) Для тысяч размещенных в памяти структур разница мажет быть существенной.

ЗАМЕЧАНИЕ. Если вы являетесь программистом С++, знайте! qsort() может быть опасной для использования с массивами объектов! qsort() осуществляет простые перемещения памяти, копируя байты. Она совершенно ничего не знает о конструкциях С++, таких, как конструкторы копирования или функции operator=(). Вместо этого используйте одну из функций сортировки STL[67] или используйте методику отдельного массива указателей.

6.2.1.2. Пример: сортировка содержимого каталога

В разделе 5.3 «Чтение каталогов» мы продемонстрировали, как элементы каталогов возвращаются в физическом порядке каталога. В большинстве случаев гораздо полезнее иметь содержимое каталога отсортированным каким-нибудь образом, например, по имени или по времени изменения. Хотя и не стандартизованные POSIX, несколько процедур упрощают это, используя qsort() в качестве лежащего в основе сортирующего агента:

#include <dirent.h> /* Обычный */


int scandir(const char *dir, struct dirent ***namelist,

 int (*select)(const struct dirent*),

 int (*compare)(const struct dirent **, const struct dirent **));

int alphasort(const void *a, const void *b);

int versionsort(const void *a, const void *b); /* GLIBC */

Функции scandir() и alphasort() были сделаны доступными в 4.2 BSD и широко поддерживаются[68], versionsort() является расширением GNU.

scandir() читает каталог, имя которого дано в dir, создает с использованием malloc() массив указателей struct dirent и устанавливает *namelist, чтобы он указывал на начало этого массива. Как массив указателей, так и указываемые структуры struct dirent выделяются с помощью malloc(); вызывающий код должен использовать free(), чтобы избежать утечек памяти.

Для выбора нужных элементов используйте указатель функции select. Когда это значение равно NULL, все действительные элементы каталога включаются в конечный массив. В противном случае (*select)() вызывается для каждого элемента, и те элементы, для которых она возвращает ненулевое (истинное) значение, включаются в массив.

Указатель функции compare сравнивает два элемента каталога. Он передается функции qsort() для использования при сортировке.

alphasort() лексикографически сравнивает имена файлов. Она использует для сравнения функцию strcoll(). strcoll() похожа на strcmp(), но учитывает связанные с местной спецификой правила сортировки (см. раздел 13.4 «Не могли бы вы написать это для меня по буквам?»).

versionsort() является расширением GNU, которое использует для сравнения имен файлов функцию GNU strverscmp() (см. strverscmp(3).) Короче говоря, эта функция понимает обычные соглашения по версиям имен файлов и сравнивает их соответствующим образом.

В ch06-sortdir.c приведена программа, похожая на ch04-catdir.c. Однако, она использует для работы scandir() и alphasort().

1  /* ch06-sortdir.c --- Демонстрирует scandir(), alphasort(). */

2

3  #include <stdio.h> /* для printf() etc. */

4  #include <errno.h> /* для errno */

5  #include <sys/types.h> /* для системных типов */

6  #include <dirent.h> /* для функций каталогов */

7

8  char *myname;

9  int process(const char *dir);

10

11 /* main --- перечислить аргументы каталога */

12

13 int main(int argc, char **argv)

14 {

15  int i;

16  int errs = 0;

17

18  myname = argv[0];

19

20  if (argc == 1)

21   errs = process("."); /* по умолчанию текущий каталог */

22  else

23   for (i = 1; i < argc; i++)

24    errs += process(argv[i]);

25

26  return (errs != 0);

27 }

28

29 /* nodots --- игнорирует файлы с точкой, для scandir() */

30

31 int

32 nodots(const struct dirent *dp)

33 {

34  return (dp->d_name[0] != '.');

35 }

36

37 /*

38  * process --- сделать что-то с каталогом, в данном случае,

39  * вывести в стандартный вывод пары индекс/имя.

40  * Вернуть 0, если все нормально, в противном случае 1.

41  */

42

43 int

44 process(const char *dir)

45 {

46  DIR *dp;

47  struct dirent **entries;

48  int nents, i;

49

50  nents = scandir(dir, &entries, nodots, alphasort);

51  if (nents < 0) {

52   fprintf(stderr, "%s: scandir failed: %s\n", myname,

53    strerror(errno));

54   return 1;

55  }

56

57  for (i = 0; i < nents; i++) {

58   printf("%81d %s\n", entries[i]->d_ino, entries[i]->d_name);

59   free(entries[i]);

60  }

61

62  free(entries);

63

64  return 0;

65 }

Функция main() программы (строки 1–27) следует стандартному шаблону, который мы использовали до этого. Функция nodots() (строки 31–35) действует как параметр select, выбирая лишь имена файлов, которые не начинаются с точки.

Функция process() (строки 43–65) довольно проста, причем scandir() делает большую часть работы. Обратите внимание, как каждый элемент отдельно освобождается с помощью free() (строка 59) и как освобождается также весь массив (строка 62).

При запуске содержимое каталога в самом деле выводится в отсортированном порядке, без '.' и '..'.

$ ch06-sortdir /* Действия по умолчанию отображают текущий каталог */

2097176 00-preface.texi

2097187 01-intro.texi

2097330 02-cmdline.texi

2097339 03-memory.texi

2097183 03-memory.texi.save

2097335 04-fileio.texi

2097334 05-fileinfo.texi

2097332 06-generall.texi

...

6.2.2. Бинарный поиск: bsearch()

Линейный поиск в значительной степени похож на свое название: вы начинаете в начале и проходите искомый массив, пока не встретите то, что нужно. Для чего-нибудь простого, типа поиска целых, это обычно принимает форму цикла for. Рассмотрите эту функцию:

/* ifind --- линейный поиск, возвращает найденный индекс или -1 */

int ifind(int x, const int array[], size_t nelems) {

 size_t i;

 for (i = 0; i < nelems; i++)

  if (array(i) == x) /* найдено */

   return i;

 return -1;

}

Преимуществом линейного поиска является его простота; легко с самого начала написать правильный код. Более того, он работает всегда. Даже если в конец массива добавляются элементы или они удаляются из него, нет необходимости сортировать массив.

Недостатком линейного поиска является то, что он медленный. В среднем для массива, содержащего nelems элементов, при линейном поиске случайного элемента требуется 'nelems/2' сравнений, прежде чем найдется нужный элемент. Это становится чрезмерно дорогим даже на современных высокопроизводительных системах, когда nelems принимает большие значения. Поэтому линейный поиск следует использовать лишь с небольшими массивами.

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

Преимуществом бинарного поиска, и значительным, является то, что бинарный поиск умопомрачительно быстр, требуя самое большее log2(N) сравнений, где N является числом элементов в массиве. Функция bsearch() объявлена следующим образом:

#include <stdlib.h> /* ISO С */


void *bsearch(const void *key, const void *base, size_t nmemb,

 size_t size, int (*compare)(const void*, const void*));

Параметры и их назначение сходны с таковыми для qsort():

const void *key

Объект, который ищется в массиве.

const void *base

Начало массива.

size_t nmemb

Число элементов в массиве.

size_t size

Размер каждого элемента, полученный с помощью sizeof.

int (*compare)(const void*, const void*)

Функция сравнения. Она должна работать таким же образом, как функция сравнения для qsort(), возвращая отрицательные/нулевые/положительные значения в соответствии с тем, меньше/равен/больше первый параметр по сравнению со вторым.

Если объект не найден, bsearch() возвращает NULL. В противном случае она возвращает указатель на найденный объект. Если key соответствует более одного объекта, какой из них будет возвращен, не определено. Поэтому, как и в случае с qsort(), убедитесь, что функция сравнения принимает во внимание все существенные части искомой структуры данных.

ch06-searchemp.c показывает bsearch() на практике, расширяя использованный ранее пример struct employee:

1  /* ch06-searchemp.с ---- Демонстрация bsearch(). */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <stdlib.h>

6

7  struct employee {

8   char lastname[30];

9   char firstname[30];

10  long emp_id;

11  time_t start_date;

12 };

13

14 /* emp_id_compare --- сравнение по ID */

15

16 int emp_id_compare(const void *e1p, const void *e2p)

17 {

18  const struct employee *e1, *e2;

19

20  e1 = (const struct employee*)e1p;

21  e2 = (const struct employee*)e2p;

22

23  if (e1->emp_id < e2->emp_id)

24   return -1;

25  else if (e1->emp_id == e2->emp_id)

26   return 0;

27  else

28   return 1;

29 }

30

31 /* print_employee --- напечатать структуру сотрудника */

32

33 void print_employee(const struct employee *emp)

34 {

35  printf("%s %s\t%d\t%s", emp->lastname, emp->firstname,

36  emp->emp_id, ctime(&emp->start_date));

37 }

Строки 7–12 определяют struct employee; она та же, что и раньше. Строки 16–29 служат в качестве функции сравнения как для qsort(), так и для bsearch(). Они сравнивают лишь ID сотрудников. Строки 33–37 определяют print_employee(), которая является удобной функцией для печати структуры, поскольку это делается из разных мест.

39 /* main --- демонстрация сортировки */

40

41 int main(int argc, char **argv)

42 {

43 #define NPRES 10

44  struct employee presidents[NPRES];

45  int i, npres;

46  char buf[BUFSIZ];

47  struct employee *the_pres;

48  struct employee key;

49  int id;

50  FILE *fp;

51

52  if (argc != 2) {

53   fprintf(stderr, "usage: %s datafile\n", argv[0]);

54   exit(1);

55  }

56

57  if ((fp = fopen(argv[1], "r")) == NULL) {

58   fprintf(stderr, "%s: %s: could not open: %s\n", argv[0],

59    argv[1], strerror(errno));

60   exit(1);

61  }

62

63  /* Очень простой код для чтения данных: */

64  for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, fp) != NULL;

65   npres++) {

66   sscanf(buf, "%s %s %ld %ld",

67    presidents[npres].lastname,

68    presidents[npres].firstname,

69    &presidents[npres].emp_id,

70    &presidents[npres].start_date);

71  }

72  fclose(fp);

73

74  /* В npres теперь число действительно прочитанных строк. */

75

76  /* Сначала отсортировать по id */

77  qsort(presidents, npres, sizeof(struct employee), emp_id_compare);

78

79  /* Напечатать результат */

80  printf("Sorted by ID:\n");

81  for (i = 0; i < npres; i++) {

82   putchar('\t');

83   print_employee(&presidents[i]);

84  }

85

86  for (;;) {

87   printf("Enter ID number: ");

88   if (fgets(buf, BUFSIZ, stdin) == NULL)

89    break;

90

91   sscanf(buf, "%d\n", &id);

92   key.emp_id = id;

93   the_pres = (structemployee*)bsearch(&key, presidents,

94    npres, sizeof(struct employee), emp_id_compare);

95

96   if (the_pres != NULL) {

97    printf("Found: ");

98    print_employee(the_pres);

99   } else

100   printf("Employee with ID %d not found'\n", id);

101  }

102

103  putchar('\n'); /* Напечатать в конце символ новой строки. */

104

105  exit(0);

106 }

Функция main() начинается с проверки аргументов (строки 52–55). Затем она читает данные из указанного файла (строки 57–72). Стандартный ввод для данных сотрудников использоваться не может, поскольку он зарезервирован для запроса у пользователя ID искомого сотрудника.

Строки 77–84 сортируют, а затем печатают данные. Затем программа входит в цикл, начинающийся со строки 86. Она запрашивает идентификационный номер сотрудника, выходя из цикла по достижению конца файла. Для поиска в массиве мы используем struct employee с именем key. Достаточно лишь установить в его поле emp_id введенный номер ID; другие поля при сравнении не используются (строка 92).

Если найден элемент с подходящим ключом, bsearch() возвращает указатель на него. В противном случае она возвращает NULL. Возвращенное значение проверяется в строке 96, и осуществляется нужное действие. Наконец, строка 102 выводит символ конца строки, чтобы системное приглашение появилось с новой строки. Вот что появляется после компилирования и запуска программы:

$ ch06-searchemp presdata.txt /* Запуск программы */

Sorted by ID:

  Carter James    39 Thu Jan 20 13:00:00 1977

  Reagan Ronald   40 Tue Jan 20 13:00:00 1981

  Bush George     41 Fri Jan 20 13:00:00 1989

  Clinton William 42 Wed Jan 20 13:00:00 1993

  Bush George     43 Sat Jan 20 13:00:00 2001

Enter ID number: 42 /* Ввод действительного номера */

Found: Clinton William 42 Wed Jan 20 13:00:00 1993 /* Найдено */

Enter ID number: 29 /* Ввод неверного номера */

Employee with ID 29 not found! /* He найдено */

Enter ID number: 40 /* Попытка другого верного номера */

Found: Reagan Ronald 40 Tue Jan 20 13:00:00 1981 /* Этот тоже найден */

Enter ID number: ^D /* CTRL-D в качестве конца файла */

$ /* Готов к приему следующей команды */

Дополнительный, более продвинутый API для поиска коллекций данных описан в разделе 14.4 «Расширенный поиск с использованием двоичных деревьев».

6.3. Имена пользователей и групп

Хотя операционная система для сохранения владельцев файлов и проверки прав доступа работает с идентификационными номерами пользователей и групп, люди предпочитают работать с именами пользователей и групп.

Ранние системы Unix хранили информацию, сопоставляющую имена с номерами ID, в простых текстовых файлах /etc/passwd и /etc/group. На современных системах эти файлы до сих пор существуют, а их формат не изменился после V7 Unix. Однако, они больше не определяют данные полностью. Большие установленные системы с множеством сетевых хостов хранят сведения в сетевых базах данных, которые представляют собой способ хранения информации на небольшом числе серверов, доступ к которым осуществляется через сеть[69]. Однако, такое использование прозрачно для большинства приложений, поскольку доступ к информации осуществляется через тот самый API, который использовался для получения сведений из текстовых файлов. Именно по этой причине POSIX стандартизует лишь API; в совместимой с POSIX системе файлы /etc/passwd и /etc/group не обязательно должны существовать.

API для этих двух баз данных похожи; большая часть обсуждения фокусируется на базе данных пользователей.

6.3.1. База данных пользователей

Традиционный формат /etc/passwd поддерживает по одной строке на пользователя. В каждой строке есть несколько полей, каждое из которых отделено от следующего символом двоеточия:

$ grep arnold /etc/passwd

arnold:x:2076:10:Arnold D. Robbins:/home/arnold:/bin/bash

По порядку эти поля следующие:

Имя пользователя

Это то, что пользователь набирает при регистрации, что отображается с помощью 'ls -l', а также используется в любом другом контексте при отображении пользователей.

Поле пароля

На старых системах здесь хранился зашифрованный пароль пользователя. На новых системах в этом поле скорее всего стоит x (как в данном случае), это означает, что сведения о пароле находятся в другом файле. Это разделение является средством обеспечения безопасности; если непривилегированному пользователю недоступен зашифрованный пароль, его значительно сложнее «взломать».

ID пользователя

Должен быть уникальным; один номер на пользователя.

ID группы

Это номер ID начальной группы пользователя. Как обсуждается далее, на современных системах с процессами связаны несколько групп.

Настоящее имя пользователя

Это по крайней мере имя и фамилия пользователя. Некоторые системы допускают разделяемые запятыми поля для местоположения офиса, номера телефона и т.д., но это не стандартизовано.

Входной каталог

Этот каталог становится домашним каталогом для пользователей, когда они зарегистрируются в системе ($HOME — по умолчанию для команды cd).

Входная программа

Программа, которая запускается при регистрации пользователя. Обычно это оболочка, но не обязательно. Если это поле оставлено пустым, по умолчанию используется /bin/sh.

Доступ к базе данных пользователей осуществляется через процедуры, объявленные в <pwd.h>:

#include <sys/types.h> /* XSI */

#include <pwd.h>


struct passwd *getpwent(void);

void setpwent(void);

void endpwent(void);


struct passwd *getpwnam(const char *name);

struct passwd *getpwuid(uid_t uid);

Поля в struct passwd, использующиеся различными процедурами API, напрямую соответствуют полям файла паролей.

struct passwd {

 char *pw_name;   /* имя пользователя */

 char *pw_passwd; /* пароль пользователя */

 uid_t pw_uid;    /* id пользователя */

 gid_t pw_gid;    /* id группы */

 char *pw_gecos;  /* настоящее имя */

 char *pw_dir;    /* домашний каталог */

 char *pw_shell;  /* программа оболочки */

};

(Имя pw_gecos историческое; когда разрабатывались ранние системы Unix, это поле содержало соответствующие сведения для учетной записи пользователя на системах Bell Labs Honeywell с операционной системой GECOS.)

Назначение каждой процедуры описано в следующем списке.

struct passwd *getpwent(void)

Возвращает указатель на внутреннюю структуру static struct passwd, содержащую сведения о «текущем» пользователе. Эта процедура читает всю базу данных паролей, по одной записи за раз, возвращая указатель на структуру для каждого пользователя. Каждый раз возвращается тот же самый указатель; т.е. для каждой записи пользователя внутренняя struct passwd переписывается заново. Когда getpwent() достигает конца базы данных паролей, она возвращает NULL. Таким образом, она позволяет пройти через всю базу данных по одному пользователю за раз. Порядок, в котором возвращаются записи, не определен.

void setpwent(void)

Сбрасывает внутреннее состояние, так что следующий вызов getpwent() возвращает первую запись в базе данных паролей.

void endpwent(void)

«Закрывает базу данных», так сказать, будь то простой файл, сетевое соединение или что-нибудь еще.

struct passwd *getpwnam(const char *name)

Ищет пользователя с членом pw_name, соответствующим name, возвращая указатель на static struct passwd, описывающий пользователя, или NULL, если пользователь не найден.

struct passwd *getpwuid(uid_t uid)

Сходным образом ищет пользователя с номером ID, приведенным в uid, возвращая указатель на static struct passwd, описывающий пользователя, или NULL, если пользователь не найден.

getpwuid() — вот что нужно, когда есть номер ID пользователя (такой, как в struct stat) и вам нужно вывести имя соответствующего пользователя. getpwnam() преобразует имя в номер ID пользователя, например, если вы хотите использовать с файлом chown() или fchown(). Теоретически обе эти процедуры осуществляют линейный поиск по базе данных паролей для обнаружения нужных сведений. На практике это верно, когда используется файл паролей, однако, кулуарные базы данных (сетевые или другие, как на системах BSD) склоняются к использованию более эффективных методов хранения, так что эти вызовы, возможно, в таком случае не такие дорогие[70].

getpwent() полезна, когда нужно пройти через всю базу данных паролей. Например, может быть необходимо прочесть ее всю в память, отсортировать, а затем осуществить быстрый поиск с помощью bsearch(). Это очень полезно для избежания множества линейных поисков, свойственных поиску по одному элементу за раз с помощью getpwuid() или getpwnam().

ЗАМЕЧАНИЕ. Указатели, возвращаемые getpwent(), getpwnam() и getpwuid(), все указывают на внутренние static данные. Поэтому следует сделать копию их содержимого, если нужно сохранить сведения.

Хорошенько рассмотрите определение struct passwd. Члены, представляющие символьные строки, являются указателями, они также указывают на внутренние static данные, и если вы собираетесь скопировать структуру, не забудьте также скопировать и данные, на которые указывает каждый член структуры.

6.3.2. База данных групп

Формат базы данных групп /etc/group подобен формату /etc/passwd, но с меньшим числом полей.

$ grep arnold /etc/group

mail:x:12:mail,postfix,arnold

uucp:x:14:uucp,arnold

floppy:x:19:arnold

devel:x:42:miriam,arnold

arnold:x:2076:arnold

Опять-таки на одну группу отводится одна строка, с полями, разделенными двоеточием. Поля следующие.

Имя группы

Это имя группы, как оно отображается в 'ls -l' или в любом другом контексте, когда требуется имя группы.

Пароль группы

Историческое поле. Оно больше не используется.

ID группы

Как и для ID пользователя, должен быть уникальным для каждой группы.

Список пользователей

Разделенный запятыми список пользователей, являющихся членами группы.

В предыдущем примере мы видели, что пользователь arnold является членом нескольких групп. Это членство на практике отражается в том, что называют набором групп (group set). Помимо главных номеров ID пользователя и ID группы, которые есть у процессов, набор групп является набором номеров ID дополнительных групп, который имеет при себе каждый процесс. Система проверяет на соответствие с этими ID групп, ID группы файла при осуществлении проверки прав доступа. Эта тема более подробно обсуждается в разделе 11 «Разрешения и ID пользователя и группы».

API базы данных групп сходна с API для базы данных пользователей. Следующие функции определены в <grp.h>:

#include <sys/types.h> /* XSI */

#include <grp.h>


struct group *getgrent(void);

void setgrent(void);

void endgrent(void);


struct group *getgrnam(const char *name);

struct group *getgrgid(gid_t gid);

struct group соответствует записям в /etc/group:

struct group {

 char *gr_name;   /* имя группы */

 char *gr_passwd; /* пароль группы */

 gid_t gr_gid;    /* id группы */

 char **gr_mem;   /* члены группы */

};

Поле gr_mem требует некоторого объяснения. Хотя оно объявлено в виде указателя на указатель (char**), лучше представить его как массив строк (наподобие argv). Последний элемент в массиве устанавливается в NULL. Когда в списке нет членов, первый элемент массива равен NULL.

ch06-groupinfo.с демонстрирует, как использовать struct group и поле gr_mem. Программа принимает в командной строке имя единственного пользователя и печатает все записи групп, в которых появляется этот пользователь:

1  /* ch06-groupinfo.с --- Демонстрация getgrent() и struct group */

2

3  #include <stdio.h>

4  #include <sys/types.h>

5  #include <grp.h>

6

7  extern void print_group(const struct group *gr);

8

9  /* main --- вывести строки групп для пользователя в argv[1] */

10

11 int

12 main(int argc, char **argv)

13 {

14  struct group *gr;

15  int i;

16

17  if (argc != 2) { /* Проверка аргументов */

18   fprintf(stderr, "usage: %s user\n", argv[0]);

19   exit(1);

20  }

21

22  while ((gr = getgrent()) != NULL) /* Получить запись каждой группы: */

23   for (i = 0; gr->gr_mem[i] != NULL; i++) /* Рассмотреть каждый член */

24    if (strcmp(gr->gr_mem[i], argv[i]) == 0) /* Если пользователь найден... */

25     print_group(gr); /* Вывести запись */

26

27  endgrent();

28

29  exit(0);

30 }

Функция main() сначала проверяет ошибки (строки 17–20). Основным компонентом программы является вложенный цикл. Внешний цикл (строка 22) перечисляет все записи базы данных группы. Внутренний цикл (строка 23) перечисляет всех членов массива gr_mem. Если один из членов соответствует имени из командной строки (строка 24), для печати записи вызывается print_group() (строка 25):

32 /* print_group --- печать записи группы */

33

34 void

35 print_group(const struct group *gr)

36 {

37  int i;

38

39  printf("%s:%s:%ld:gr->gr_name, gr->gr_passwd, (long)gr->gr_gid);

40

41  for (i = 0; gr->gr_mem[i] != NULL; i++) {

42   printf("%s", gr->gr_mem[i]);

43   if (gr->gr_mem[i+1) != NULL)

44    putchar(',');

45  }

46

47  putchar('\n');

48 }

Функция print_group() (строки 34–48) проста, ее логика подобна логике main() для печати списка членов. Члены списка группы разделены запятыми; поэтому тело цикла до вывода запятой должно проверить, что следующий элемент в массиве не является NULL. Этот код работает правильно, даже если в группе нет членов. Однако мы знаем, что для этой программы есть члены, иначе print_group() не была бы вызвана! Вот что происходит при запуске программы:

$ ch06-groupinfo arnold

mail:x:12:mail,postfix,arnold

uucp:x:14:uucp,arnold

floppy:x:19:arnold

devel:x:42:miriam,arnold

arnold:x:2076:arnold

6.4. Терминалы: isatty()

Модель стандартного ввода, стандартного вывода и стандартной ошибки Linux/Unix препятствует специальной трактовке устройств ввода и вывода. Программам обычно не нужно знать или беспокоиться о том, направляется ли их вывод на терминал, в файл, канал, физическое устройство или что-то еще.

Однако иногда бывают моменты, когда программе действительно нужно знать, с какого рода файлом связан файловый дескриптор. Семейство вызовов stat() часто предоставляет достаточно сведений обычный файл, каталог, устройство и т.д. Хотя иногда даже этого недостаточно, и для интерактивных программ, в частности, вам может потребоваться знать, не представляет ли дескриптор файла tty.

tty (сокращение для Teletype, одного из ранних производителей компьютерных терминалов) является любым устройством, представляющим терминал, т.е. нечто, что человек мог бы использовать для взаимодействия с компьютером. Это может быть либо аппаратное устройство, такое, как клавиатура и монитор персонального компьютера, или старинный терминал видеодисплея, соединенный с компьютером через последовательный порт или модем, или программный псевдотерминал, такой, который используется в оконных системах и при сетевых регистрациях.

Различить можно с помощью isatty().

#include <unistd.h> /* POSIX */


int isacty(int desc);

Эта функция возвращает 1, если дескриптор файла desc представляет терминал, в противном случае 0. В соответствии с POSIX isatty() может установить errno для указания ошибки; поэтому до вызова isatty() следует установить errno в 0, а затем проверить ее значение, если был возвращен 0. (Справочная страница GNU/Linux isatty(3) не упоминает об использовании errno.) Стандарт POSIX также указывает, что просто возврат isatty() 1 не означает, что на другом конце дескриптора файла находится человек!

Одним местом, где используется isatty(), является современная версия ls, в которой имена файлов по умолчанию печатаются в столбцы, если терминалом является стандартный вывод, а если нет, они печатаются по одной на строчку.

6.5. Рекомендуемая литература

1. Mastering Algorithms With C by Kyle Loudon. O'Reilly & Associates, Sebastopol, California, USA, 1999. ISBN: 1-56592-453-3.

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

2. The Art of Computer Programming Volume 3. Sorting and Searching, 2nd edition, by Donald E. Knuth Addison-Wesley, Reading Massachusetts, USA, 1998. ISBN: 0-201-89685-0.[71]

На эту книгу обычно ссылаются как на последнее слово в сортировке и поиске. Примите во внимание, что она значительно более сжата и труднее для чтения, чем книга Loudon'a.

3. Проект GTK+[72] состоит из нескольких совместно работающих библиотек GTK+ является лежащим в основе инструментарием, используемым проектом GNU GNOME.[73] В основе иерархии библиотек располагается Glib, библиотека фундаментальных типов, структур данных и функций для работы с ними. Glib включает возможности для всех основных операций, которые мы до сих пор рассмотрели в данной книге, и многое другое, включая связанные списки и хэш-таблицы. Для просмотра онлайн-документов начните с веб-сайта проекта документации GTK+[74], щелкните на ссылке «Загрузить» (Download) и идите дальше по онлайн-версии.

6.6. Резюме

• Время внутренне хранится в виде значений time_t, представляющих «секунды с начала Эпохи». Эпоха для систем GNU/Linux и Unix начинается с полночи 1 января 1970 г. по UTC. Текущее время получается от системы с помощью системного вызова time(), а difftime() возвращает разницу в секундах между двумя значениями time_t.

• Структура struct tm представляет «разложенное время», которое является значительно более удобным представлением даты и времени. gmtime() и localtime() преобразуют значения time_t в значения struct tm, a mktime() действует в обратном направлении.

• asctime() и ctime() осуществляют упрошенное форматирование значений времени, возвращая указатель на static строку символов фиксированного размера и формата, strftime() предусматривает гораздо более гибкое форматирование, включая значения на основе местных настроек.

• Сведения о часовом поясе доступны через вызов tzset(). Поскольку стандартные процедуры действуют так, как если бы они автоматически вызывали tzset(), необходимость в непосредственном вызове этой функции возникает редко.

• Стандартной процедурой для сортировки массивов является qsort(). Используя предоставленную пользователем функцию сравнения и принимая параметры числа элементов массива и их размера, qsort() может сортировать любые виды данных. Это обеспечивает значительную гибкость.

• scandir() читает в массив struct dirent каталог целиком. Для выбора того, какие элементы включить в массив и для обеспечения упорядочения элементов в массиве могут использоваться предоставленные пользователем функции alphasort() является стандартной функцией для сортировки элементов каталога по имени; scandir() передает функцию сортировки прямо через qsort().

• Функция bsearch() работает подобно qsort(). Она осуществляет быстрый бинарный поиск. Используйте ее, если цена линейного поиска перевешивает цену сортировки ваших данных. (Дополнительный API для поиска коллекций данных описан в разделе 14.4 «Расширенный поиск с помощью двоичных деревьев».)

• Базы данных пользователей и групп могут храниться в файлах на локальном диске или могут быть доступны через сеть. Стандартный API намеренно скрывает это различие. Каждая база данных обеспечивает как линейный просмотр всей базы данных, так и непосредственные запросы имени или ID пользователя/группы.

• Наконец, для тех случаев, когда недостаточно простого stat(), isatty() может вам сообщить, представляет ли открытый файл устройство терминала.

Упражнения

1. Напишите простую версию команды date, которая принимает в командной строке строку формата и использует ее для форматирования и вывода текущего времени.

2. Когда файл старше шести месяцев, 'ls -l' использует для печати времени изменения более простой формат. GNU версия файла ls.c использует следующее вычисление:

3043 /* Время считается недавним, если оно в пределах последних 6

3044    месяцев. В Григорианском годе 365.2425 * 24 * 60 * 60 ==

3045    31556952 секунд в среднем. Запишите это значение как

3046    целую константу для избежания трудностей с плавающей точкой.*/

3047    six_months_ago = current_time - 31556952 / 2;

Сравните это с нашим примером вычисления шести прошлых месяцев. Каковы преимущества и недостатки каждого из методов?

3. Напишите простую версию команды touch, которая изменяет время модификации файла, имя которого указано в командной строке, на текущее время

4. Добавьте к вашей команде touch опцию, которая принимает в командной строке значения даты и времени и использует их в качестве нового времени модификации файлов, указанных в командной строке.

5. Добавьте к своей версии touch еще одну опцию, которая принимает имя файла и использует время модификации данного файла как новое время модификации файла, указанного в командной строке.

6. Усовершенствуйте ch06-sortemp.c так, чтобы она сортировала отдельный массив указателей, указывающих на массив сотрудников.

7. Добавьте к ch06-sortdir.c опции для сортировки по номеру индекса, времени модификации, времени доступа и размеру. Добавьте «обратную опцию», так, чтобы основанная на времени сортировка первым помещала самый недавний файл, а по другим критериям (размеру, индексу) помещала вначале наибольшее значение.

8. Напишите простую версию команды chown. Она должна использоваться так:

chown пользователь[:группа] файлы ...

Здесь пользователь и группа являются именами пользователя и группы, представляющими новых пользователя и группу для указанных файлов. Группа необязательна; если она присутствует, она отделяется от пользователя двоеточием. Чтобы протестировать свою версию на системе GNU/Linux, вы должны зарегистрироваться в качестве root. Делайте это осторожно!

9. Усовершенствуйте свою chown, чтобы допустить использование числовых значений пользователя или группы наряду с их именами.

10. Напишите функции для копирования структур пользователя и группы, включая указываемые данные. Для выделения памяти используйте при необходимости malloc().

11. Напишите специализированную библиотеку поиска пользователей, которая считывает в динамически выделяемый массив всю базу данных пользователей. Предусмотрите быстрый поиск пользователей как по ID, так и по именам. Гарантируйте обработку случая, при котором запрошенный пользователь не найден.

12. Сделайте то же самое для базы данных групп.

13. Напишите программу stat, которая печатает содержимое struct stat для каждого файла, указанного в командной строке. Она должна выводить все значения в формате, удобном для восприятия человеком: значения time_t в виде дат и времени, значения uid_t и gid_t в виде соответствующих имен (если они доступны), а также содержимое символических ссылок. Выведите поле st_mode таким же образом, как вывела бы ls.

Сравните свою программу с программой stat GNU Coreutils как по их выводу, так и по исходному коду.

Глава 7 Соединяя все вместе: ls

Команда V7 ls хорошо связывает воедино все, что мы до сих пор видели. Она использует почти все API, которые мы рассмотрели, затрагивая многие аспекты программирования Unix: выделение памяти, вспомогательные данные файлов, времена и даты, имена пользователей, чтение каталогов и сортировку.

7.1. Опции V7 ls

По сравнению с современными версиями ls, V7 ls принимает лишь небольшое количество опций, а значение некоторых из них для V7 отличается от значения для современной ls. Эти опции следующие:

 Выводит все элементы каталога. Без нее '.' и '..' не выводятся. Довольно интересно, V7 игнорирует лишь '.' и '..', тогда как с V1 по V6 игнорируется любой файл, имя которого начинается с точки. Это последнее является также поведением по умолчанию и для современных версий ls.

-n Вместо времени модификации файла использует для -t или -l время изменения индекса.

-d Для аргументов каталогов выводит сведения о самом каталоге, а не о его содержимом.

-f «Заставляет» читать каждый элемент как каталог и печатать найденное в каждом слоте имя. Эта опция отключает -l, -r, -s, -t и включает . (Эта опция, очевидно, существует для отладки и исправления файловой системы.)

-g Для 'ls -l' использует вместо имени пользователя имя группы.

-i Выводит в первом столбце номер индекса вместе с именем файла или длинным листингом.

-l Осуществляет привычный вывод в длинном формате. Обратите, однако, внимание, что V7 'ls -l' выводила лишь имя владельца, а не имена владельца и группы вместе.

-r Изменяет порядок сортировки, будь то по алфавиту для имен файлов или по времени.

-s Выводит размер файла в 512-байтовых блоках. Справочная страница V7 ls(1) утверждает, что вспомогательные блоки (indirect blocks) — блоки, используемые файловой системой для обнаружения блоков больших файлов — также учитываются при вычислении, но, как мы увидим, это утверждение было неверным.

-t Сортирует вывод вместо имени по времени модификации, сначала более ранние.

-u С опциями -t и/или -l использует время доступа вместо времени модификации. Наибольшие различия между V7 ls и современной ls затрагивают опцию и опцию -l. Современные системы опускают все файлы с точками, если не указана , и они включают в длинный листинг -l имена и владельца, и группы. На современных системах -g означает вывод лишь имени группы, а -o означает вывод лишь имени владельца. Стоит заметить, что у GNU ls свыше 50 опций!

7.2. Код V7 ls

Файл /usr/src/cmd/ls.c в дистрибутиве V7 содержит код. Весь он занимает 425 строк.

1  /*

2   * перечисляет файлы или каталоги

3   */

4

5  #include <sys/param.h>

6  #include <sys/stat.h>

7  #include <sys/dir.h>

8  #include <stdio.h>

9

10 #define NFILES 1024

11 FILE *pwdf, *dirf;

12 char stdbuf[BUFSIZ];

13

14 struct lbuf { /* Собирает необходимые сведения */

15  union {

16   char lname[15];

17   char *namep;

18  } ln;

19  char ltype;

20  short lnum;

21  short lflags;

22  short lnl;

23  short luid;

24  short lgid;

25  long lsize;

26  long lmtime;

27 };

28

29 int aflg, dflg, lflg, sflg, tflg, uflg, lflg, fflg, gflg, cflg;

30 int rflg = 1;

31 long year; /* Глобальные переменные: инициализируются 0 */

32 int flags;

33 int lastuid = -1;

34 char tbuf[16];

35 long tblocks;

36 int statreq;

37 struct lbuf *flist[NFILES];

38 struct lbuf **lastp = flist;

39 struct lbuf **firstp = flist;

40 char *dotp = ".";

41

42 char *makename(); /* char *makename(char *dir, char *file); */

43 struct lbuf *gstat(); /* struct lbuf *gstat(char *file, int argfl); */

44 char *ctime(); /* char *ctime(time_t *t); */

45 long nblock(); /* long nblock(long size); */

46

47 #define ISARG 0100000

Программа начинается с включения файлов (строки 5–8) и объявлений переменных. struct lbuf (строки 14–27) инкапсулирует части struct stat, которые интересны ls. Позже мы увидим, как эта структура заполняется.

Переменные aflg, dflg и т.д. (строки 29 и 30) все указывают на наличие соответствующей опции. Такой стиль именования переменных типичен для кода V7. Переменные flist, lastp и firstp (строки 37–39) представляют файлы, о которых ls выводит сведения. Обратите внимание, что flist является массивом фиксированного размера, которая позволяет обрабатывать не более 1024 файлов. Вскоре мы увидим, как используются все эти переменные.

После объявлений переменных идут объявления функций (строки 42–45), а затем определение ISARG, которая различает файл, указанный в командной строке, от файла, найденного при чтении каталога.

49 main(argc, argv) /* int main(int argc, char **argv) */

50 char *argv[];

51 {

52  int i;

53  register struct lbuf *ep, **ep1; /* Объявления переменных и функций */

54  register struct lbuf **slastp;

55  struct lbuf **epp;

56  struct lbuf lb;

57  char *t;

58  int compar();

59

60  setbuf(stdout, stdbuf);

61  time(&lb.lmtime); /* Получить текущее время */

62  year = lb.lmtime - 6L*30L*24L*60L*60L; /* 6 месяцев назад */

Функция main() начинается с объявления переменных и функций (строки 52–58), устанавливая буфер для стандартного вывода, получая время дня (строки 60–61) и вычисляя значение секунд с начала Эпохи для примерно шести месяцев (строка 62). Обратите внимание, что у всех констант есть суффикс L, указывающий на использование арифметики long.

63  if (--argc > 0 && *argv[1] == '-') {

64   argv++;

65   while (*++*argv) switch(**argv) { /* Разбор опций */

66

67   case 'a': /* Все элементы каталога */

68    aflg++;

69    continue;

70

71   case 's': /* Размер в блоках */

72    sflg++;

73    statreq++;

74    continue;

75

76   case 'd': /* Сведения о каталоге, не содержание */

77    dflg++;

78    continue;

79

80   case 'g': /* Имя группы вместо имени владельца */

81    gflg++;

82    continue;

83

84   case 'l': /* Расширенный листинг */

85    lflg++;

86    statreq++;

87    continue;

88

89   case 'r': /* Обратный порядок сортировки */

90    rflg = -1;

91    continue;

92

93   case 't': /* Сортировка по времени, не по имени */

94    tflg++;

95    statreq++;

96    continue;

97

98   case 'u': /* Время доступа, а не изменения */

99    uflg++;

100   continue;

101

102  case 'c': /* Время изменения индекса, а не файла */

103   cflg++;

104   continue;

105

106  case 'i': /* Включить номер индекса */

107   iflg++;

108   continue;

109

110  case 'f': /* Форсировать чтение каждого arg как каталога */

111   fflg++;

112   continue;

113

114   default: /* Незнакомые буквы опций игнорировать */

115    continue;

116  }

117  argc--;

118 }

Строки 63–118 разбирают опции командной строки. Обратите внимание на ручной разбор кода: getopt() еще не была придумана. Переменная statreq устанавливается в true, когда опция требует использования системного вызова stat().

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

В современных системах индексы находятся в группах, распределенных по всей файловой системе, вместо объединения их вместе в начале. Это дает заметный прирост производительности. Тем не менее, вызовы stat() до сих пор не бесплатны, вы должны использовать их лишь при необходимости, но не более.

119 if (fflg) { /* -f аннулирует -l, -s, -t, добавляя -a */

120  aflg++;

121  lflg = 0;

122  sflg = 0;

123  tflg = 0;

124  statreq = 0;

125 }

126 if (lflg) { /* Открыть файл паролей или групп */

127  t = "/etc/passwd";

128  if (gflg)

129   t = "/etc/group";

130  pwdf = fopen(t, "r");

131 }

132 if (argc==0) { /* Если нет аргументов, использовать текущий */

133  argc++;

134  argv = &dotp - 1;

135 }

Строки 119–125 обрабатывают опцию -f, выключая -l, -s, -t и statreq. Строки 126–131 обрабатывают -l, устанавливая для файла чтение сведений о владельце или группе. Помните, что V7 показывает лишь одно из этих сведений, но не оба.

Если аргументов больше не осталось, строки 132–135 устанавливают argv таким образом, что он указывает на строку, представляющую текущий каталог. Назначение 'argr = &dotp - 1' действительно, хотя и необычно. '- 1' компенсирует '++argv' в строке 137. Это позволяет избежать в главной части программы специального случая для 'argc == 1'.

136  for (i=0; i < argc; i++) { /* Получить сведения о каждом файле */

137   if ((ер = gstat(*++argv, 1))==NULL)

138    continue;

139   ep->ln.namep = *argv;

140   ep->lflags |= ISARG;

141  }

142  qsort(firstp, lastp - firstp, sizeof *lastp, compar);

143  slastp = lastp;

144  for (epp=firstp; epp<slastp; epp++) { /* Глав. код, см. текст */

145   ер = *epp;

146   if (ep->ltype=='d' && dflg==0 || fflg) {

147    if (argc>1)

148     printf("\n%s:\n", ep->ln.namep);

149    lastp = slastp;

150    readdir(ep->ln.namep);

151    if (fflg==0)

152     qsort(slastp, lastp - slastp, sizeof *lastp, compar);

153    if (lflg || sflg)

154     printf("total %D\n", tblocks);

155    for (ep1=slastp; ep1<lastp; ep1++)

156     pentry(*ep1);

157   } else

158   pentry(ep);

159  }

160  exit(0);

161 } /* Конец main() */

Строки 136–141 перебирают аргументы, собирая сведения о каждом. Второй аргумент gstat() булевый: true, если имя является аргументом командной строки, в противном случае false. Строка 140 добавляет флаг ISARG к полю lflags для каждого аргумента командной строки.

Функция gstat() добавляет каждую новую struct lbuf к глобальному массиву flist (строка 137). Она также обновляет глобальный указатель lastp, чтобы он указывал в этом массиве на текущий последний элемент.

Строки 142–143 сортируют массив, используя qsort(), и сохраняют текущее значение lastp в slastp. Строки 144–159 перебирают в цикле каждый элемент массива, выводя соответствующим образом сведения о файле или каталоге.

Код для каталогов заслуживает дальнейшего объяснения:

if (ep->ltype=='d' && dflg==0 || fflg) ...

Строка 146. Если файл является каталогом и -d не предусмотрено или было установлено -f, ls должна прочесть каталог вместо того, чтобы выводить сведения о самом каталоге.

if (argc>1) printf ("\n%s:\n", ep->ln.namep)

Строки 147–148. Выводят имя каталога и двоеточие, если в командной строке было указано несколько файлов.

lastp = slastp;

readdir(ep->ln.namep)

Строки 149–150. Восстанавливают lastp из slastp. Массив flist действует как двухуровневый стек имен файлов. Аргументы командной строки хранятся с firstp до slastp - 1. Когда readdir() читает каталог, она помещает структуры struct lbuf для содержимого каталога в стек, начиная с slastp и до lastp. Это показано на рис. 7.1.

Рис. 7.1. Массив flist как двухуровневый стек

if (fflg==0) qsort(slastp, lastp - slastp, sizeof *lastp, compar)

Строки 151–152. Сортируют элементы подкаталога, если не действует -f.

if (lflg || sflg) printf("total %D\n", tblocks)

Строки 153–154. Выводят для -l или -s общее число блоков, используемых файлами в каталоге. Эта сумма хранится в переменной tblocks, которая сбрасывается для каждого каталога. На современных системах форматирующая строка %D для printf() эквивалентна %ld; она означает «вывести длинное целое». (В V7 есть также %ld, см. строку 192.)

for (ep1=slastp; ep1<lastp; ep1++) pentry(*ep1)

Строки 155–156. Выводит сведения о каждом файле в подкаталоге. Обратите внимание, что V7 ls спускается лишь на один уровень в дереве каталогов. У нее отсутствует современная «рекурсивная» опция -R.

163 pentry(ap) /* void pentry(struct lbuf *ap) */

164 struct lbuf *ap;

165 {

166  struct { char dminor, dmajor;}; /* He использующийся исторический артефакт из V6 ls */

167  register t;

168  register struct lbuf *p;

169  register char *cp;

170

171  p = ap;

172  if (p->lnum == -1)

173   return;

174  if (iflg)

175   printf("%5u ", p->lnum); /* Номер индекса */

176  if (sflg)

177   printf("%4D nblock(p->lsize)); /* Размер в блоках */

Процедура pentry() выводит сведения о файле. Строки 172–173 проверяют, установлен ли -1 в поле lnum, и если так, функция возвращается. Когда верно 'p->lnum == -1', структура struct lbuf недействительна. В противном случае это поле содержит номер индекса файла.

Строки 174–175 выводят номер индекса, если действует -i. Строки 176–177 выводят общее число блоков, если действует -s. (Как мы увидим ниже, это число может быть неточным.)

178  if (lflg) { /* Расширенный листинг: */

179   putchar(p->ltype); /* - Тип файла */

180   pmode(p->lflags); /* - Права доступа */

181   printf("%2d ", p->lnl); /* - Число ссылок */

182   t = p->luid;

183   if (gflg)

184    t = p->lgid;

185   if (getname(t, tbuf)==0)

186    printf("%-6.6s", tbuf); /* - Владелец или группа */

187   else

188    printf("%-6d", t);

189   if (p->ltype=='b' || p->ltype=='c') /* - Устройство: старший и младший номера */

190    printf("%3d,%3d", major((int)p->lsize), minor((int)p->lsize));

191   else

192    printf("%71d", p->lsize); /* - Размер в байтах */

193   cp = ctime(&p->lmtime);

194   if (p->lmtime < year) /* - Время изменения */

195    printf(" %-7.7s %-4.4s ", cp+4, cp+20); else

196    printf(" %-12.12s ", cp+4);

197  }

198  if (p->lflags & ISARG) /* - Имя файла */

199   printf("%s\n", p->ln.namep);

200  else

201   printf("%.14s\n", p->ln.lname);

202 }

Строки 178–197 обрабатывают опцию -l. Строки 179–181 выводят тип файла, права доступа и число ссылок. Строки 182–184 устанавливают t на ID владельца или группы, в зависимости от опции -g. Строки 185–188 получают соответствующее имя и выводят его, если оно доступно. В противном случае программа выводит числовое значение.

Строки 189–192 проверяют, является ли файл блочным или символьным устройством. Если да, они выводят старшее и младшее номера устройств, извлеченные с помощью макросов major() и minor(). В противном случае они выводят размер файла.

Строки 193–196 выводят соответствующее время. Если оно старше шести месяцев, код выводит месяц, день и год. В противном случае, выводятся месяц, день и время (формат результата с time() см. раздел 6.1.3.1 «Простое форматирование времени: asctime() и ctime()»).

Наконец, строки 198–201 выводят имя файла. Мы знаем, что для аргумента командной строки это завершающаяся нулем строка, и может быть использована %s. Для файла, прочитанного из каталога, оно может не завершаться нулем, поэтому должна использоваться явно указанная точность, %.14s.

204 getname(uid, buf) /* int getname(int uid, char buf[]) */

205 int uid;

206 char buf[];

207 {

208  int j, c, n, i;

209

210  if (uid==lastuid) /* Простое кэширование, см. текст */

211   return(0);

212  if (pwdf == NULL) /* Проверка безопасности */

213   return(-1);

214  rewind(pwdf); /* Начать с начала файла */

215  lastuid = -1;

216  do {

217   i = 0; /* Индекс в массиве buf */

218   j = 0; /* Число полей в строке */

219   n = 0; /* Преобразование числового значения */

220   while ((c=fgetc(pwdf)) != '\n') { /* Прочесть строки */

221    if (c==EOF)

222     return(-1);

223    if (c==':') { /* Число полей*/

224     j++;

225     c = '0';

226    }

227    if (j==0) /* первое поле - имя */

228     buf[i++] = c;

229    if (j==2) /* Третье поле - числовой ID */

230     n = n*10 + c - '0';

231   }

232  } while (n != uid); /* Продолжать до обнаружения ID */

233  buf[i++] = '\0';

234  lastuid = aid;

235  return(0);

236 }

Функция getname() преобразует ID владельца или группы в соответствующее имя. Она реализует простую схему кэширования; если переданное uid то же самое, которое находится в глобальной переменной lastuid, функция возвращает 0 (все нормально), буфер уже содержит имя (строки 210–211). lastuid инициализируется в -1 (строка 33), поэтому этот тест не проходит, когда getname() вызывается первый раз.

pwdf уже открыт либо в /etc/passwd, либо в /etc/group (см. строки 126–130). Код здесь проверяет, что открытие было успешным, и если нет, возвращает -1 (строки 212–213).

Удивительно, ls не использует getpwuid() или getgrgid(). Вместо этого она использует преимущество того факта, что формат /etc/passwd и /etc/group идентичен для трех первых полей (имя, пароль, числовой ID) и что оба используют в качестве разделителя двоеточие.

Строки 216–232 реализуют линейный поиск по файлу. j содержит число обнаруженных до сих пор двоеточий: 0 для имени и 2 для ID. Таким образом, при сканировании строки она заполняет как имя, так и ID.

Строки 233–235 завершают буфер name, устанавливают в глобальной lastuid последний найденный ID и возвращают 0 для обозначения успеха.

238 long /* long nblock(long size) */

239 nblock(size)

240 long size;

241 {

242  return ((size+511) >>9);

243 }

Функция nblock() сообщает, сколько дисковых блоков использует файл. Это вычисление основано на размере файла, возвращенном stat(). Размер блока V7 равен 512 байтам — размер физического сектора диска.

Вычисление в строке 242 выглядит несколько устрашающим. '>>9' является сдвигом вправо на девять битов. Это осуществляет деление на 512 дляполучения числа блоков. (На раннем аппаратном обеспечении сдвиг вправо выполнялся гораздо быстрее деления.) Пока все хорошо. Теперь, файл даже размером в один байт все равно занимает целый дисковый блок. Однако, '1 / 512' дает ноль (целое деление срезает), что неверно. Это объясняет 'size+511'. Добавляя 511, этот код гарантирует, что сумма дает правильное число блоков при делении на 512.

Это вычисление, однако, лишь приблизительное. У очень больших файлов есть также дополнительные блоки. Несмотря на заявление в справочной странице V7 ls(1), данное вычисление не принимает в расчет дополнительные блоки.

Более того, рассмотрите случай файла с большими дырами (созданными установкой указателя файла дальше конца файла с помощью lseek()). Дыры не занимают дисковых блоков; однако, это не отражается в значении размера. Поэтому вычисления, выполненные nblock(), будучи обычно верными, могут давать результаты больше или меньше реальных.

По этим причинам в struct stat 4 2 BSD были добавлены члены st_blocks, которые затем были приняты для System V и POSIX.

245 int m1[] = { 1, S_IREAD>>0, 'r', '-' };

246 int m2[] = { 1, S_IWRITE>>0, 'w', '-' };

247 int m3[] = { 2, S_ISUID, 's', S_IEXEC>>0, 'x', '-' };

248 int m4[] = { 1, S_IREAD>>3, 'r', '-' };

249 int m5[] = { 1, S_IWRITE>>3, 'w', '-' };

250 int m6[] = { 2, S_ISGID, 's', S_IEXEC>>3, 'x', '-' };

251 int m7[] = { 1, S_IREAD>>6, 'r', '-' };

252 int m8[] = { 1, S_IWRITE>>6, 'w', '-' };

253 int m9[] = { 2, S_ISVTX, ' t', S_IEXEC>>6, 'x', '-' };

254

255 int *m[] = { m1, m2, m3, m4, m5, m6, m7, m8, m9 };

256

257 pmode(aflag) /* void pmode(int aflag) */

258 {

259  register int **mp;

260

261  flags = aflag;

262  for (mp = &m[0]; mp < &m[sizeof(m)/sizeof(m[0])];)

263   select(*mp++);

264 }

265

266 select(pairp) /* void select(register int *pairp) */

267 register int *pairp;

268 {

269  register int n;

270

271  n = *pairp++;

272  while (--n>=0 && (flags&*pairp++)==0)

273   pairp++;

274  putchar(*pairp);

275 }

Строки 245–275 выдают права доступа к файлу. Код компактен и довольно элегантен, он требует тщательного изучения.

• Строки 245–253: массивы с m1 по m9 кодируют биты прав доступа для проверки вместе с соответствующими буквами для вывода. На каждую выводимую букву режима файла имеется один массив. Первый элемент каждого массива является числом пар (право доступа, буква), закодированных в данном конкретном массиве. Последний элемент является буквой, которая должна быть выведена в случае, если не найден ни один из битов прав доступа.

Обратите также внимание, что права доступа обозначены как 'I_READ>>0', 'I_READ>>3', 'I_READ>>6' и т.д. Отдельные константы для каждого бита (S_IRUSR, S_IRGRP и т.п.) не были еще придуманы. (См. табл. 4.5 в разделе 4 6.1 «Указание начальных прав доступа к файлу».)

• Строка 255: массив m указывает на каждый из массивов с m1 по m9.

• Строки 257–264: функция pmode() сначала устанавливает глобальную переменную flags равной переданному параметру aflag. Затем она просматривает в цикле массив m, передавая каждый элемент функции select(). Переданный элемент представляет один из массивов с m1 по m9.

• Строки 266–275: функция select() понимает структуру каждого из массивов с m1 по m9. n является числом пар в массиве (первый элемент); его устанавливает строка 271. Строки 272–273 ищут биты прав доступа, проверяя установленную ранее в строке 261 глобальную переменную flags.

Обратите внимание на использование оператора ++ как в проверке цикла, так и в теле цикла. Результатом является пропуск пары в массиве, если в flags не обнаружен бит доступа в первом элементе пары.

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

Последним стоящим внимания моментом является то, что на С символьные константы (такие как 'x') имеют тип int, а не char[75]. Поэтому проблем с помещением этих констант в массив целых нет; все работает правильно.

277 char* /* char *makename(char *dir, char *file) */

278 makename(dir, file)

279 char *dir, *file;

280 {

281  static char dfile[100];

282  register char *dp, *fp;

283  register int i;

284

285  dp = dfile;

286  fp = dir;

287  while (*fp)

288   *dp++ = *fp++;

289  *dp++ = '/';

290  fp = file;

291  for (i=0; i<DIRSIZ; i++)

292   *dp++ = * fp++;

293  *dp = 0;

294  return(dfile);

295 }

Строки 277–295 определяют функцию makename(). Ее работа заключается в соединении имени каталога с именем файла, разделенным символом косой черты, с образованием строки. Она осуществляет это в static буфере dfile. Обратите внимание, что dfile всего лишь 100 символов длиной и что проверка ошибок не выполняется.

Сам код прост, он копирует по одному символу за раз. makename() используется функцией readdir().

297 readdir(dir) /* void readdir(char *dir) */

298 char *dir;

299 {

300  static struct direct dentry;

301  register int j;

302  register struct lbuf *ep;

303

304  if ((dirf = fopen(dir, "r")) == NULL) {

305   printf("%s unreadable\n", dir);

306   return;

307  }

308  tblocks = 0;

309  for(;;) {

310   if (fread((char*)&dentry, sizeof(dentry), 1, dirf) != 1)

311    break;

312   if (dentry.d_ino==0

313    || aflg==0 && dentry.d_name[0]=='.' && (dentry.d_name[1]=='\0'

314    || dentry.d_name[1]=='.' && dentry, d_name[2]=='\0'))

315    continue;

316   ep = gstat(makename(dir, dentry.d_name), 0);

317   if (ep==NULL)

318    continue;

319   if (ep->lnum != -1)

320    ep->lnum = dentry.d_ino;

321   for (j =0; j<DIRSIZ; j++)

322    ep->ln.lname[j] = dentry.d_name[j];

323  }

324  fclose(dirf);

325 }

Строки 297–325 определяют функцию readdir(), чья работа заключается в чтении содержимого каталогов, указанных в командной строке.

Строки 304–307 открывают каталог для чтения, завершая функцию, если fopen() возвращает ошибку. Строка 308 инициализирует глобальную переменную tblocks нулем. Ранее (строки 153–154) это использовалось для вывода общего числа блоков, использованных файлами в каталоге.

Строки 309–323 являются циклом, который читает элементы каталога и добавляет их к массиву flist. Строки 310–311 читают один элемент, выходя из цикла в конце файла.

Строки 312–315 пропускают неинтересные элементы. Если номер индекса равен нулю, этот слот не используется. В противном случае, если не был указан -а и имя файла является '.' или '..', оно пропускается.

Строки 316–318 вызывают gstat() с полным именем файла и вторым аргументом, равным false, указывающим, что он не из командной строки. gstat() обновляет глобальный указатель lastp и массив flist. Возвращаемое значение NULL обозначает какую-нибудь разновидность ошибки.

Строки 319–322 сохраняют номер индекса и имя в struct lbuf. Если ep->lnum возвращается из gstat() установленным в -1, это означает, что операция stat() с файлом завершилась неудачей. Наконец, строка 324 закрывает каталог.

Следующая функция, gstat() (строки 327–398), является центральной функцией для получения и сохранения сведений о файле.

327 struct lbuf * /* struct lbuf *gstat(char *file, int argfl) */

328 gstat(file, argfl)

329 char *file;

330 {

331  extern char *malloc();

332  struct stat statb;

333  register struct lbuf *rep;

334  static int nomocore;

335

336  if (nomocore) /* Ранее была нехватка памяти */

337   return(NULL);

338  rep = (struct lbuf*)malloc(sizeof(struct lbuf));

339  if (rep==NULL) {

340   fprintf(stderr, "ls: out of memory\n");

341   nomocore = 1;

342   return(NULL);

343  }

344  if (lastp >= &flist[NFILES]) { /* Проверить, не дано ли слишком много файлов */

345   static int msg;

346   lastp--;

347   if (msg==0) {

348    fprintf(stderr, "ls: too many files\n");

349    msg++;

350   }

351  }

352  *lastp++ = rep; /* Заполнить сведения */

353  rep->lflags = 0;

354  rep->lnum = 0;

355  rep->ltype = '-'; /* Тип файла по умолчанию */

Статическая переменная nomocore [важно] указывает, что malloc() при предыдущем вызове завершилась неудачей. Поскольку она статическая, она автоматически инициализируется 0 (т.е. false). Если на входе она равна true, gstat() просто возвращает NULL. В противном случае, если malloc() завершается неудачей, ls выводит сообщение об ошибке, устанавливает в nomocore true и возвращает NULL (строки 334–343).

Строки 344–351 гарантируют, что в массиве flist все еще остается место. Если нет, ls выдает сообщение (но лишь однажды; заметьте использование статической переменной msg), а затем повторно использует последний слот flist.

Строка 352 заставляет слот lastp указывать на новую struct lbuf (rep). Это также обновляет lastp, который используется для сортировки в main() (строки 142 и 152). Строки 353–355 устанавливают значения по умолчанию для полей флагов, номеров индексов и типов в struct lbuf.

356  if (argfl || statreq) {

357   if (stat(file, &statb)<0) { /* stat() завершилась неудачей */

358    printf("%s not found\n", file);

359    statb.st_ino = -1;

360    statb.st_size = 0;

361    statb.st_mode = 0;

362    if (argfl) {

363     lastp--;

364     return(0);

365    }

366   }

367   rep->lnum = statb.st_ino; /* stat() OK, копировать сведения */

368   rep->lsize = statb.st_size;

369   switch(statb.st_mode & S_IFMT) {

370

371   case S_IFDIR:

372    rep->ltype = 'd';

373    break;

374

375   case S_IFBLK:

376    rep->ltype = 'b';

377    rep->lsize = statb.st_rdev;

378    break;

379

380   case S_IFCHR:

381    rep->ltype = 'c';

382    rep->lsize = statb.st_rdfev;

383    break;

384   }

385   rep->lflags = statb.st_mode & ~S_IFMT;

386   rep->luid = statb.st_uid;

387   rep->lgid = statb.st_gid;

388   rep->lnl = statb.st_nlink;

389   if (uflg)

390    rep->lmtime = statb.st_atime;

391   else if (cflg)

392    rep->lmtime = statb.st_ctime;

393   else

394    rep->lmtime = statb.st_mtime;

395   tblocks += nblock(statb.st_size);

396  }

397  return(rep);

398 }

Строки 356–396 обрабатывают вызов stat(). Если это аргумент командной строки или если statreq установлен в true благодаря опции, код заполняет struct lbuf следующим образом:

• Строки 357–366: вызывают stat(), при ее неудаче выводится сообщение об ошибке с установкой соответствующих значений, затем возвращается NULL (выраженный в виде 0).

• Строки 367–368: устанавливают в struct stat поля номера индекса и размера, если вызов stat() был успешным.

• Строки 369–384: обрабатывают особые случаи каталогов, блочных и символьных устройств. Во всех случаях код обновляет поле ltype. Для устройств значение lsize замещается значением st_rdev.

• Строки 385–388. заполняются поля lflags, luid, lgid и lnl из соответствующих полей в struct stat. Строка 385 удаляет биты типа файла, оставляя 12 битов прав доступа (на чтение/запись/исполнение для владельца/группы/остальных, а также setuid, setgid и save-text).

• Строки 389–394: основываясь на опциях командной строки, используют одно из трех полей времени в struct stat для поля lmtime в struct lbuf.

• Строка 395: обновляет глобальную переменную tblocks числом блоков в файле.

400 compar(pp1, pp2) /* int compar(struct lbuf **pp1, */

401 struct lbuf **pp1, **pp2; /* struct lbuf **pp2) */

402 {

403  register struct lbuf *p1, *p2;

404

405  p1 = *pp1;

406  p2 = *pp2;

407  if (dflg==0) {

408   if (p1->lflags&ISARG && p1->ltype=='d') {

409    if (!(p2->lflags&ISARG && p2->ltype=='d'))

410     return(1);

411   } else {

412    if (p2->lflags&ISARG && p2->ltype=='d')

413     return(-1);

414   }

415  }

416  if (tflg) {

417   if(p2->lmtime == p1->lmtime)

418    return(0);

419   if (p2->lmtime > p1->lmtime)

420    return(rflg);

421   return(-rflg);

422  }

423  return(rflg * strcmp(p1->lflags&ISARG ? p1->ln.namep : p1->ln.lname,

424   p2->lflags&ISARG ? p2->ln.namep : p2->ln.lname));

425 }

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

Следующая вещь, которую нужно понять, это то, что ls выводит содержимое каталогов после выведения сведений о файлах. Поэтому результат сортировки должен быть таким, чтобы все каталоги, указанные в командной строке, следовали за всеми файлами, указанными там же

Наконец, переменная rflg помогает реализовать опцию -r, которая меняет порядок сортировки. Она инициализируется 1 (строка 30). Если -r используется, rflg устанавливается в -1 (строки 89–91).

Следующий псевдокод описывает логику compar(); номера строк на левой границе соответствуют номерам строк ls.c:

407 if ls должна прочесть каталоги # dflg == 0

408  if p1 аргумент командной строки и p1 каталог

409   if p2 не аргумент командной строки и не каталог

410    return 1 # первый идет после второго

      else

       перейти на тест времени

411  else

      # p1 не каталог командной строки

412   if p2 аргумент командной строки и каталог

413    return -1 # первый идет перед вторым

      else

       перейти на тест времени

416 if сортировка основана на времени # tflg равно true

     # сравнить времена:

417  if время p2 равно времени p1

418   return 0

419  if время p2 > времени p1

420   return значение rflg (положительное или отрицательное)

     # время p2 < времени p1

421  return противоположное rflg значение (положительное или отрицательное)

423 Умножить rflg на результат strcmp()

424 для двух имен и вернуть результат

Аргументы strcmp() в строках 423–424 выглядят сбивающими с толку. В зависимости от того, было ли имя файла указано в командной строке или было прочитано из каталога, должны использоваться различные члены объединения ln в struct lbuf.

7.3. Резюме

• V7 ls является сравнительно небольшой программой, хотя она затрагивает многие фундаментальные аспекты программирования Unix — файловый ввод-вывод, вспомогательные данные файлов, содержание каталогов, пользователи и группы, значения времени и даты, сортировку и динамическое управление памятью.

• Наиболее примечательным внешним различием между V7 ls и современной ls является трактовка опций и -l. У версии V7 значительно меньше опций, чем у современных версий; заметным недостатком является отсутствие рекурсивной опции -R.

• Управление flist является чистым способом использования ограниченной памяти архитектуры PDP-11, предоставляя в то же время как можно больше сведений, struct lbuf хорошо извлекает нужные сведения из struct stat; это значительно упрощает код. Код для вывода девяти битов доступа компактен и элегантен.

• Некоторые части ls используют удивительно маленькие лимиты, такие, как верхняя граница числа файлов в 1024 или размер буфера в makename() в 100.

Упражнения

1. Рассмотрите функцию getname(). Что случится, если запрошенный ID равен 256, а в /etc/passwd есть следующие две строки, в этом порядке:

joe:xyzzy:2160:10:Joe User:/usr/joe:/bin/sh

jane:zzyxx:216:12:Jane User:/usr/jane:/bin/sh

2. Рассмотрите функцию makename(). Может ли она использовать sprintf() для составления имени? Почему может или почему нет?

3. Являются ли строки 319–320 в readdir() действительно необходимыми?

4. Возьмите программу stat, которую вы написали в качестве упражнения в «Упражнениях» к главе 6. Добавьте функцию nblock() из V7 ls и выведите результаты вместе с полем st_blocks из struct stat. Добавьте видимый маркер, когда они различны.

5. Как бы вы оценили V7 ls по ее использованию malloc()? (Подсказка: как часто вызывается free()? Где ее следовало бы вызвать?)

6. Как вы оценили бы ясность кода V7 ls? (Подсказка: сколько там комментариев?)

7. Очертите шаги, которые нужно было бы сделать, чтобы адаптировать V7 ls для современных систем.

Глава 8 Файловые системы и обходы каталогов

Данная глава завершает обсуждение файловых систем и каталогов Linux (и Unix). Сначала мы опишем, как к логическому пространству имен файловой системы добавляется (и удаляется) раздел диска, содержащий файловую систему, таким образом, что в общем пользователю не нужно ни знать, ни заботиться о месте физического размещения файла, вместе с API для работы с файловыми системами

Затем мы опишем, как перемещаться по иерархическому пространству имен файлов, как получать полный путь текущего рабочего каталога и как без труда обрабатывать произвольные иерархии (деревья) каталогов, используя функцию nftw(). Наконец, мы опишем специализированный, но важный системный вызов chroot().

8.1. Монтирование и демонтирование файловых систем

Унифицированное иерархическое пространство имен файлов является большим достоинством дизайна Linux/Unix. Данный раздел рассматривает, как административные файлы, команды и операционная система объединяются для построения пространства имен из отдельных физических устройств, содержащих данные и служебные данные файлов.

8.1.1. Обзор основ

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

Помимо индексов и блоков данных, файловые системы содержат также одну или более копий суперблока. Это специальный дисковый блок, который описывает файловую систему; его сведения обновляются по мере изменений в самой файловой системе. Например, он содержит число свободных и используемых индексов, свободных и используемых блоков и другие сведения. Он включает также магическое число: специальное уникальное значение в специальном месте, которое идентифицирует тип файловой системы (Вскоре мы увидим, насколько это важно.)

Обеспечение доступа к разделу, содержащему файловую систему, называется монтированием (mounting) файловой системы. Удаление файловой системы из использования называется, что неудивительно, демонтированием (unmounting) файловой системы.

Эти две задачи выполняются программами mount и umount [так], названными по соответствующим системным вызовам. У системного вызова mount() каждой системы Unix свой, отличный интерфейс. Поскольку монтирование и демонтирование считаются проблемой реализации, POSIX намеренно не стандартизует эти системные вызовы

Вы монтируете файловую систему в каталог; такой каталог называется точкой монтирования файловой системы. По соглашению, каталог должен быть пустым, но ничто не принуждает к этому. Однако, если точка монтирования не пуста, все ее содержимое становится , пока в ней не смонтирована файловая система[76].

Ядро поддерживает уникальный номер, известный как номер устройства, который идентифицирует каждый смонтированный раздел. По этой причине именно пара (устройство, индекс) вместе уникально идентифицируют файл; когда структуры struct stat для двух имен файлов указывают, что оба эти номера одни и те же, можно быть уверенным, что они на самом деле ссылаются на один и тот же файл.

Как упоминалось ранее, программы уровня пользователя помещают структуры индексов и другие вспомогательные данные на раздел диска, создавая тем самым файловую систему. Эти самые программы создают для файловой системы начальный корневой каталог. Таким образом, нам придется провести различие между «корневым каталогом, названным /», который является каталогом самого верхнего уровня в иерархическом пространстве имен файлов, и «корневым каталогом файловой системы», который является отдельным каталогом верхнего уровня каждой файловой системы. Каталог / является также «корневым каталогом» «корневой файловой системы».

По причинам, описанным на врезке, у корневого каталога файловой системы номер индекса всегда равен 2 (хотя это не стандартизовано формально). Поскольку может быть несколько файловых систем, у каждой из них один и тот же номер индекса корневого каталога 2. При разрешении пути ядро знает, где смонтирована каждая файловая система и заставляет имя точки монтирования ссылаться на корневой каталог смонтированной файловой системы. Более того, '..' в корне смонтированной файловой системы ссылается на родительский каталог точки монтирования.

На рис. 8.1 показаны две файловые системы: одна для корневого каталога, а другая для /usr, до того, как /usr смонтирована. На рис. 8.2 показана ситуация после монтирования /usr.

Рис. 8.1. Отдельные файловые системы до монтирования

Рис. 8.2. Отдельные файловые системы после монтирования

Каталог /, корень всей логической иерархии, особый еще в одном отношении: /. и /.. ссылаются на один и тот же каталог; это неверно для любого другого каталога в системе. (Таким образом, после команды типа 'cd /../../../..' вы все еще будете в /.) Это поведение реализуется простым способом: как /., так и /.. являются прямыми ссылками на корневой каталог файловой системы. (Вы можете видеть это как на рис. 8.1, так и 8.2.) Каждая файловая система работает таким способом, но ядро рассматривает / особым образом и не рассматривает как особый случай каталог '..' для файловой системы, смонтированной в /.

Номера индексов корневого каталога
Номер индекса для корневого каталога файловой системы всегда равен 2. Почему это так? Ответ имеет отношение как к технологии, так и к истории.

Как упоминалось в разделе 5.3 «Чтение каталогов», элемент каталога с номером индекса ноль означает неиспользуемый, или пустой слот. Поэтому индекс 0 не может использоваться для настоящего файла или каталога.

Хорошо, так что насчет индекса 1? Ну, особенно в 70-80 годах XX века, диски не были сделаны так же хорошо, как сейчас. Когда вы покупали диск, он приходил с (бумажным) списком испорченных блоков — известных мест на диске, которые не могли быть использованы. Каждой операционной системе приходилось отслеживать эти плохие блоки и избегать их использования.

Под Unix это осуществлялось созданием файла особого назначения, блоки данных которого были известны, как испорченные. Этот файл присоединялся к индексу 1, оставляя 2 в качестве первого индекса, доступного для использования обычными файлами или каталогами.

На современных дисках присутствует значительное количество встроенной электроники, и они сами управляют испорченными блоками. Поэтому технически было бы осуществимо использовать для файла индекс 1. Однако, поскольку такое большое количество программ Unix, которые предполагают, что индекс 2 является индексом для корневых каталогов файловых систем, Linux также следует этому соглашению. (Однако, Linux иногда использует индекс 1 для не собственных файловых систем, таких, как vfat или /proc.)

8.1.2. Обзор различных типов файловых систем

ЗАМЕЧАНИЕ. Обсуждение в данном разделе специфично для Linux. Однако, у многих современных систем Unix также есть сходные особенности. Мы рекомендуем вам изучить документацию своей системы.

Исторически V7 Unix поддерживал лишь один тип файловой системы; вспомогательные данные и организация каталогов каждого из разделов были структурированы одним и тем же способом. 4.1 BSD использовал файловую систему с такой же как у V7 структурой, но с размером блока 1024 байта вместо 512 байтов. 4.2 BSD ввело «файловую систему BSD», которая разительно изменила расположение индексов и данных на диске и дала возможность использовать гораздо большие размеры блоков. (В общем, использование больших протяженных блоков данных обеспечивает лучшую производительность, особенно для чтения файлов.)

Вплоть до 4.3 BSD и System V Release 2 в начале и середине 1980-х системы Unix продолжали поддерживать один тип файловой системы. Для переключения компьютера от одной файловой системы на другую[77] приходилось сначала резервировать каждую файловую систему на среду архивирования (9-дорожечную ленту), обновлять систему, а затем восстанавливать данные.

В середине 1980-х Sun Microsystems разработала архитектуру ядра, которая сделала возможным использование нескольких архитектур файловой системы в одно и то же время. Этот проект был реализован в их операционной системе SunOS, сначала для поддержки сетевой файловой системы Sun (Network File System — NFS). Однако, как следствие, стало возможным также поддерживать несколько архитектур на диске. System V Release 3 использовала сходную архитектуру для поддержки удаленной файловой системы (Remote File System — RFS), но она продолжала поддерживать лишь одну архитектуру на диске.[78] (RFS никогда широко не использовалась и сейчас является лишь исторической сноской.)

Общий дизайн Sun стал популярным и широко реализовывался в коммерческих системах Unix, включая System V Release 4. Системы Linux и BSD используют разновидность этого дизайна для поддержки множества форматов файловых систем на диске. В частности, обычным для всех разновидностей Unix на платформе Intel x86 является возможность монтирования файловых систем MS-DOS/Windows FAT, включая поддержку длинных имен, а также форматированные в соответствии с ISO 9660 CD-ROM.

Linux имеет несколько собственных (т.е. размещаемых на диске) файловых систем. Наиболее популярными являются файловые системы ext2 и ext3. Однако, доступно значительно больше файловых систем. Сведения о большинстве из них вы можете найти в каталоге /usr/src/linux/Documentation/filesystems/ (если вы установили исходный код ядра). В табл. 8.1 перечислены имена различных файловых систем с кратким описанием каждой из них. Сокращение «RW» означает «чтение/запись», a «RO» означает «только чтение».


Таблица 8.1. Поддерживаемые ядром файловые системы Linux (ядро 2.4.x)

Имя Режим Описание
afs RW Andrew File System (файловая система Andrew)
adfs RW Acorn Advanced Disc Filing System (расширенная дисковая файловая система Acorn)
affs RO, RW Amiga Fast File system (быстрая файловая система Amiga) Режим «только для чтения» в противоположность режиму «для записи и чтения» зависит от версии файловой системы
autofs RW Файловая система для взаимодействия с демоном автоматического монтирования
befs RO Файловая система BeOS. Помечена как программное обеспечение альфа.
bfs RW SCO UnixWare Boot File system (загрузочная файловая система SCO Unix).
binfmt-misc RW Специальная файловая система для запуска интерпретаторов компилированных файлов (например, файлов Java)
efs RW Файловая система, разработанная для варианта Unix SGI, названного Irix
coda RW Экспериментальная распределенная файловая система, разработанная в CMU[79]
cramfs RO Небольшая файловая система для хранения файлов в постоянной памяти (ROM).
devfs RW Способ динамического предоставления файлов для /dev (устарело).
devpts RW Специальная файловая система для псевдотерминалов.
ext2 RW Вторая расширенная файловая система. Файловая система по умолчанию для GNU/Linux, хотя некоторые дистрибутивы используют теперь ext3.
ext3 RW Файловая система ext2 с журналированием
hfs RW Hierarchical File System (иерархическая файловая система) Apple Mac OS.
hpfs RW High Performance File System (высокопроизводительная файловая система) OS/2.
intermezzo RW Экспериментальная распределенная файловая система для работы в отсоединенном от сети состоянии. См веб-сайт InterMezzo (http://www.inter-mezzo.org)
jffs RW Journalled Flash File system (журналируемая файловая система с групповой записью/считыванием, для встроенных систем)
jffs2 RW Journalled Flash File system 2 (тоже для встроенных систем)
iso9660 RO Файловая система ISO 9660 для CD-ROM. Поддерживаются также расширения Rock Ridge, заставляющие выглядеть использующие их CD-ROM как нормальная файловая система (но только для чтения).
jfs RW Journalled File System (журналируемая файловая система) IBM для Linux.
ncp RW Протокол Novell NCP для NetWare; клиент удаленной файловой системы.
ntfs RO Поддержка файловой системы NTFS Windows
openpromfs RO Файловая система /proc для PROM на системах SPARC
proc RW Доступ к информации о процессах и ядре
qnx4 RW Файловая система QNX4 (небольшой операционной системы реального времени)
ramfs RW Файловая система для создания RAM-дисков.
reiserfs RW Развитая журналируемая файловая система
romfs RO Файловая система для создания простых RAM-дисков только для чтения.
smbfs RW Поддержка клиента для файловых систем SMB (разделяемых файлов Windows)
sysv RW Файловые системы System V Release 2, Xenix, Minix и Coherent. coherent, minix и xenix являются псевдонимами
tmpfs RW Файловая система электронного диска, поддерживающая динамический рост.
udf RO Формат файловой системы UDF, используемый в DVD-ROM
ufs RO, RW Быстрая файловая система BSD, на современных системах с доступом для чтения и записи.
umsdos RW Расширение vfat, заставляющее выглядеть ее подобно файловой системе Unix
usbfs RW Специальная файловая система для работы с устройствами USB. Первоначальным именем было usbdevfs, это имя до сих пор появляется, например, в выводе mount
vfat RW Все варианты файловых систем FAT MS-DOS/Windows Компонентами являются msdos и fat
vxfs RW Журналируемая файловая система Veritas VxFS.
xfs RW Высокопроизводительная журналирующая файловая система, разработанная SGI для Linux. См веб-сайт XFS (http://oss.sgi.com/projects/xfs/)
Не все из этих файловых систем поддерживаются командой mount; список поддерживаемых см. в mount(8).

Журналирование является методикой, впервые использованной в системах баз данных для увеличения производительности обновлений файлов таким образом, что восстановление файловой системы в случае аварии могло быть сделано быстро и правильно. В момент написания этого были доступны несколько различных журналируемых файловых систем, конкурирующих за продвижение в мире GNU/Linux. Одной из них является ext3; у нее преимущество обратной совместимости с существующими файловыми системами ext2, очень просто конвертировать файловые системы туда-сюда между этими двумя видами (См. tune2fs(8).) ReiserFS и XFS также имеют своих твердых сторонников.

Файловые системы fat, msdos, umsdos и vfat все разделяют общий исходный код. В общем, можно использовать vfat для монтирования разделов Windows FAT-32 (или другой FAT-xx), a umsdos, если нужно использовать раздел FAT в качестве корневой файловой системы для GNU/Linux.

Файловые системы Coherent, MINIX, первоначальной System V и Xenix все имеют сходные структуры на диске. Тип файловой системы sysv поддерживает все из них; четыре имени coherent, minix, sysv и xenix являются псевдонимами один для другого. Имена coherent и xenix в конечном счете будут удалены.

Быстрая файловая система BSD в течение нескольких лет успешно развилась. Файловая система ufs поддерживает операции чтения/записи для версий, начиная с 4.4 BSD, которая является основой для трех широко распространенных операционных систем BSD: FreeBSD, NetBSD и OpenBSD. Она поддерживает также операции чтения/записи для файловой системы Sun Solaris как для SPARC, так и для систем Intel x86. Первоначальный формат BSD и формат операционной системы NeXTStep поддерживаются в режиме только для чтения.

Обозначения «RO» для befs и ntfs означают, что файловые системы этих типов можно смонтировать и читать, но в них невозможно записать файлы или удалить из них файлы. (Со временем это может измениться; проверьте документацию своей системы.) Файловые системы cramfs, iso9660, romfs и udf отмечены «RO», поскольку лежащее в их основе средство по своей сути является устройством только для чтения.

Две файловые системы, которых больше не существует, это ext, которая была оригинальной расширенной файловой системой, и xiafs, которая расширяла оригинальную файловую систему MINIX для использования длинных имен и больших размеров файлов, xiafs и ext2 появились примерно в одно время, но ext2 в конечном счете стала доминирующей файловой системой.[80]

8.1.3. Монтирование файловых систем: mount

Команда mount монтирует файловые системы, соединяя их содержимое в системную иерархию файлов в их точках монтирования. Под GNU/Linux это иногда запутано, поскольку приходится иметь дело со всеми известными типами файловых систем и их опциями. Обычно запустить mount может лишь root, хотя в некоторых случаях можно сделать исключения, как в случае, обсуждаемом далее в главе.

Файловую систему вы указываете с помощью опции -t:

mount [опции] устройство точка_монтирования

Например (# является приглашением для root):

# mount -t iso9660 /dev/cdrom /mnt/cdrom /* Монтировать CD-ROM */

# mount -t vfat /dev/fd0 /mnt/floppy /* Монтировать гибкий диск MS-DOS */

# mount -t nfs files.example.com:/ /mnt/files /* Монтировать файловую систему NFS */

Можно использовать '-t auto', чтобы заставить mount угадать тип файловой системы. Это обычно работает, хотя если вы точно знаете, каков тип файловой системы, опция '-t' помогает указать тип и избежать вероятности ошибочного определения файловой системы, mount по умолчанию угадывает нужный тип, поэтому '-t auto' не является абсолютно необходимым.

Системы GNU/Linux предусматривают специальную разновидность монтирования посредством кольцевого (loopback) устройства. Таким способом образ файловой системы, содержащийся в обычном файле, может быть смонтирован, как если бы это было настоящее дисковое устройство. Эта возможность очень полезна, например, при использовании образов CD-ROM. Она позволяет создать образ и испытать его без необходимости прожига на болванке CD с последующим его монтированием. Следующий пример использует первый образ CD из дистрибутива GNU/Linux RedHat 9:

# ls -l shrike-i386-discl.iso /* Исследование файла образа CD */

-rw-r--r-- 1 arnold devel 668991488 Apr 11 05:13 shrike-i386-discl.iso

# mount -t iso9660 -o ro,loop shrike-i386-discl.iso /mnt/cdrom

/* Смонтировать его в /mnt/cdrom */

# cd /mnt/cdrom /* Перейти туда */

# ls /* Посмотреть файлы */

autorun              README.it             RELEASE-NOTES-fr.html

dosutils             README.ja             RELEASE-NOTES.html

EULA                 README.ko             RELEASE-NOTES-it.html

GPL                  README.pt             RELEASE-NOTES-ja.html

images               README.pt_BR          RELEASE-NOTES-ko.html

isolinux             README.zh_CN          RELEASE-NOTES-pt_BR.html

README               README.zh_TW          RELEASE-NOTES-pt.html

README-Accessibility RedHat                RELEASE-NOTES-zh_CN.html

README.de            RELEASE-NOTES         RELEASE-NOTES-zh_TW.html

README.es            RELEASE-NOTES-de.html RPM-GPG-KEY

README.fr            RELEASE-NOTES-es.html TRANS.TBL

# cd /* Сменить */

# umount /mnt/cdrom /* Демонтировать */

Возможность монтирования таким способом образа ISO 9660 особенно полезна при тестировании сценариев, создающих образы CD. Вы можете создать образ в обычном файле, смонтировать его и проверить, что он подготовлен правильно. Затем, убедившись, что все в порядке, можно скопировать образ на записываемый CD («прожечь» CD). Возможность кольцевого устройства полезна также для монтирования образов гибких дисков

8.1.4. Демонтирование файловых систем: umount

Команда umount демонтирует файловую систему, удаляя ее содержимое из системной иерархии файлов. Использование следующее:

umount файл-или-устройство

Демонтируемая файловая система не должна быть занята. Это означает, что нет процессов с открытыми в файловой системе файлами и что ни у одного процесса текущий рабочий каталог не находится в этой файловой системе:

$ mount /* Показать, что смонтировано */

/dev/hda2 on / type ext3 (rw) /* / находится на настоящем устройстве */

none on /proc type proc (rw)

usbdevfs on /proc/bus/usb type usbdevfs (rw)

/dev/hda5 on /d type ext3 (rw) /* To же c /d */

none on /dev/pts type devpts (rw,gid=5,mode=620)

none on /dev/shm type tmpfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

$ su /* Переключиться на суперпользователя */

Password: /* Пароль не отображается */

# cd /d /* Сделать /d текущим каталогом */

# umount /d /* Попытка демонтировать /d */

umount: /d: device is busy /* Doesn't work; it's still in use */

# cd / /* Сменить /d */

# umount /d /* Еще одна попытка демонтировать /d */

# /* Молчание золото: umount работает */

8.2. Файлы для администрирования файловой системы

Файл /etc/fstab[81] перечисляет файловые системы, которые могут быть смонтированы. Большинство из них монтируются автоматически, когда система загружается. Формат следующий:

устройство точка-монтированиятип-фс опции dump-freq fsck-pass

(dump-freq и fsck-pass являются административными особенностями, не относящимися к настоящему обсуждению). Например, на нашей системе файл выглядит следующим образом:

$ cat /etc/fstab

# device mount-point type options freq passno

/dev/hda3 / ext3 defaults 1 1 /* Корневая файловая система */

/dev/hda5 /d ext3 defaults 1 2

none /dev/pts devpts gid=5,mode=620 0 0

none /proc proc defaults 0 0

none /dev/shm tmpfs defaults 0 0

# Windows partition:

/dev/hda1 /win vfat noauto,defaults,user,uid=2076,gid=10 0 0

/dev/hda3 swap swap defaults 0 0

/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0 /* Монтируемый */

/dev/fd0 /mnt/floppy auto noauto,owner 0 0/* Гибкий диск, то же самое */

Разрешены комментарии, начинающиеся с #. Вскоре, в разделе 8.2 1 «Использование опций монтирования», будет обсуждение различных опций.

Тот же самый формат файла используется для /etc/mtab, куда mount записывает информацию о файловых системах, когда они смонтированы; umount удаляет информацию из этого файла, когда файловая система демонтирована:

$ cat /etc/mtab

/dev/hda2 / ext3 rw 0 0

none /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw,gid=5,mode=620 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,noexec,nosuid,nodev,uid=2076,gid=10,user=arnold 0 0

Ядро делает доступным (почти) те же самые сведения в /proc/mounts, в том же формате:

$ cat /proc/mounts

rootfs / rootfs rw 0 0

/dev/root / ext3 rw 0 0

/proc /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,nosuid,nodev,noexec 0 0

Обратите внимание, что в /etc/mtab есть некоторые сведения, которые отсутствуют в /proc/mounts. (Например, см. строку для точки монтирования /win.) С другой стороны, возможно (используя 'mount -f') помещать в /etc/mtab элементы, которые не являются настоящими (эта практика имеет свое применение, см. mount(8)). Подводя итог, /proc/mounts всегда описывает, что смонтировано в действительности; однако, /etc/mtab содержит сведения об опциях mount, которых нет в /proc/mounts. Поэтому, чтобы получить полную картину, вам может понадобиться прочесть оба файла

8.2.1. Использование опций монтирования

Команда mount поддерживает опции, которые контролируют то, какие операции ядро будет позволять или не позволять применять к файловой системе. Их приличное количество. Лишь две из них полезны на самом деле в командной строке:

ro

Монтирует файловую систему только для чтения. Это необходимо для устройств только для чтения, таких, как CD-ROM и DVD.

loop

Использует кольцевое устройство для интерпретации обычного файла в качестве файловой системы. Пример этого мы показали ранее (см. раздел 8.1.3 «Монтирование файловых систем: mount»).

Опции передаются с опцией командной строки -о и могут группироваться, отделяясь запятыми. Например, вот использованная ранее командная строка:

mount -t iso9660 -о ro,loop shrike-i386-discl.iso /mnt/cdrom

Оставшиеся опции предназначены для использования в /etc/fstab (хотя они могут использоваться также и в командной строке). Следующий список представляет те опции, которые, как мы полагаем, наиболее важны в повседневном использовании.

auto, noauto

Файловые системы, помеченные auto, должны монтироваться при загрузке системы через 'mount -а' (монтировать все файловые системы). Файловые системы noauto должны монтироваться вручную. Они по-прежнему находятся в /etc/fstab вместе с другими файловыми системами. (См., например, элемент /win для показанного ранее файла /etc/fstab).

defaults

Использует по умолчанию опции rw, suid, dev, exec, auto, nouser и async. (async является продвинутой опцией, повышающей производительность ввода/вывода).

dev, nodev

Позволяет (не позволяет) использовать в файловой системе файлы символьных или блочных устройств.

exec, noexec

Позволяет (не позволяет) запускать в файловой системе двоичные исполняемые файлы.

user, nouser

Позволяет (не позволяет) монтировать данную файловую систему любому пользователю. Это полезно для CD-ROM; даже если вы находитесь на рабочей станции с одним пользователем, удобно не переключаться на root просто для монтирования CD. Демонтировать файловую систему может лишь пользователь, который смонтировал ее. user предполагает наличие опций noexec, nosuid и nodev.

suid, nosuid

Поддерживает (не поддерживает) биты setuid и setgid исполняемых файлов в файловой системе.

rw

Монтирует файловую систему в режиме для чтения/записи.

Опции nodev, noexec и nosuid особенно ценны для безопасности на файловых системах гибких дисков и CD-ROM. Рассмотрите студенческую среду, в которой студентам разрешено монтировать собственные гибкие диски или CD. Тривиально смастерить для жесткого диска файловую систему с оболочкой setuid-root или с файлом устройства с разрешением записи для всех, которая позволила бы предприимчивому пользователю изменить права доступа к системным файлам.

У каждой файловой системы есть специфичные для нее опции. Важной опцией для ext2 и ext3 является grpid. Мы отложим обсуждение этой опции до раздела 11.5.1 «Группа по умолчанию для новых файлов и каталогов». Подробности для всех поддерживаемых файловых систем можно найти в справочной странице mount(8).

В качестве конкретного примера вернемся к строчке для раздела Windows в нашей системе:

# device mount-point type options freq passno

/dev/hda1 /win vfat noauto,defaults,user,uid=2076,gid=10 0 0

Опция noauto предотвращает монтирование раздела Windows при загрузке. Опция defaults та же самая, что rw, suid, dev, exec, async. Опция user позволяет нам монтировать файловую систему, не будучи root. Опции uid= и gid= делает файлы в /win принадлежащими нам, так что нам не нужно иметь права root при работе с этим разделом.

8.2.2. Работа со смонтированными файловыми системами: getmntent()

Любой из файлов /etc/fstab, /etc/mtab и /proc/mounts может быть прочитан программное использованием набора процедур getmntent():

#include <stdio.h> /* GLIBC */

#include <mntent.h>


FILE *setmntent(const char *filename, const char *type);

struct mntent *getmntent(FILE *filep);

int addmntent(FILE *filep, const struct mntent *mnt);

int endmntent(FILE *filep);

char *hasmntopt(const struct mntent *mnt, const char *opt);

setmntent() открывает файл, содержащий элементы точек монтирования. Аргумент filename является файлом, который должен быть открыт. Аргумент type похож на второй аргумент fopen(), указывая доступ для чтения, записи или чтения/записи. (Рассмотрите команду mount, которой приходится добавлять элемент к /etc/mtab для каждой файловой системы, которую она монтирует, и umount, которая должна удалять этот элемент.) Затем возвращаемое значение типа FILE* используется с оставшимися процедурами.

getmntent() читает файл, возвращая указатель на static struct mntent, которая заполнена соответствующими значениями. Это статическое хранилище переписывается при каждом вызове. Когда больше не осталось элементов, она возвращает NULL. (Это сходно с процедурами для чтения файлов паролей и групп; см раздел 6.3 «Имена пользователей и групп».)

addmntent() вызывается для добавления сведений в конец открытого файла, она предназначена для использования функцией mount.

endmntent() закрывает открытый файл; вызывайте ее после завершения обработки. Не вызывайте просто fclose(); может потребоваться очистить другие внутренние структуры данных, связанные с переменной FILE*.

hasmntopt() является более специализированной функцией. Она просматривает struct mntent, переданную в качестве первого параметра, в поисках опции mount, совпадающей со вторым аргументом. Если опция найдена, она возвращает адрес совпадающей подстроки. В противном случае возвращается NULL.

Поля в struct mntent непосредственно соответствуют полям в файле /etc/fstab. Структура выглядит следующим образом:

struct mntent {

 char *mnt_fsname; /* Устройство или сервер для файл. С-мы. */

 char *mnt_dir;    /* Каталог для монтирования. */

 char *mnt_type;   /* Тип файловой системы: ufs, nfs и т.д. */

 char *mnt_opts;   /* Отделяемые запятыми опции для fs. */

 int mnt_freq;     /* Частота дампа (в днях). */

 int mnt_passno;    /* Номер для 'fsck'. */

};

Обычным принципом работы со смонтированными файловыми системами является создание внешнего цикла, читающего /etc/mtab, обрабатывая по одной struct mntent за раз. Наш первый пример, ch08-mounted.c, делает именно это:

1  /* ch08-mounted.с --- вывод списка смонтированных файловых

2     систем */

3  /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */

4

5  #include <stdio.h>

6  #include <errno.h>

7  #include <mntent.h> /* для getmntent() и др. */

8  #include <unistd.h> /* для getopt() */

9

10 void process(const char *filename);

11 void print_mount(const struct mntent *fs);

12

13 char *myname;

14

15 /* main --- обработка опций */

16

17 int main(int argc, char **argv)

18 {

19  int c;

20  char *file = "/etc/mtab"; /* файл по умолчанию для чтения */

21

22  myname = argv[0];

23  while ((c = getopt(argc, argv, "f:")) != -1) {

24   switch (c) {

25   case 'f':

26    file = optarg;

27    break;

28   default:

29    fprintf(stderr, "usage: %s [-f fstab-file]\n", argv[0]);

30    exit(1);

31   }

32  }

33

34  process(file);

35  return 0;

36 }

37

38 /* process --- прочесть структуры struct mntent из файла */

39

40 void process(const char *filename)

41 {

42  FILE *fp;

43  struct mntent *fs;

44

45  fp = setmntent(filename, "r"); /* только для чтения */

46  if (fp == NULL) {

47   fprintf(stderr, "%s: %s: could not open: %s\n",

48    myname, filename, strerror(errno));

49   exit(1);

50  }

51

52  while ((fs = getmntent(fp)) != NULL)

53   print_mount(fs);

54

55  endmntent(fp);

56 }

57

58 /* print_mount --- вывод одного смонтированного элемента */

59

60 void print_mount(const struct mntent *fs)

61 {

62  printf("%s %s %s %s %d %d\n",

63   fs->mnt_fsname,

64   fs->mnt_dir,

65   fs->mnt_type,

66   fs->mnt_opts,

67   fs->mnt_freq,

68   fs->mnt_passno);

69 }

В отличие от большинства программ, которые мы до сих пор видели, эта специфична для Linux. Во многих Unix-системах есть схожие процедуры, но их идентичность не гарантируется.

По умолчанию, ch08-mounted читает /etc/mtab, выводя сведения о каждой смонтированной файловой системе. Опция -f позволяет указать другой файл для чтения, такой, как /proc/mounts или даже /etc/fstab.

Функция main() обрабатывает командную строку (строки 23–32) и вызывает для указанного файла process(). (Эта программа следует нашему стандартному шаблону.)

process(), в свою очередь, открывает файл (строка 45) и проходит в цикле через каждую возвращённую файловую систему (строки 52–53). После завершения она закрывает файл (строка 55).

Функция print_mount() выводит информацию из struct mnent. Вывод во многом напоминает вывод 'cat /etc/mtab':

$ ch08-mounted /* Запуск программы */

/dev/hda2 / ext3 rw 0 0

none /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw,gid=5,mode=620 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,noexec,nosuid,nodev,uid=2076,gid=10,user=arnold 0 0

8.3. Получение сведений о файловой системе

Вывод сведений о файловой системе, рассмотренный ранее — это хорошо и замечательно, но это не захватывает. Раз мы знаем, что определенная точка монтирования представляет файловую систему, нам нужны сведения о файловой системе. Это даст нам возможность выводить вещи наподобие сведений, полученных с помощью df и 'df -i'.

$ df /* Показать свободное/используемое пространство */

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/hda2 6198436 4940316 943248 84% /

/dev/hda5 61431520 27618536 30692360 48% /d

none 256616 0 256616 0% /dev/shm

/dev/hda1 8369532 2784700 5584832 34% /win

$ df -i /* Показать свободные/используемые индексы */

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/hda2 788704 233216 555488 30% /

/dev/hda5 7815168 503243 7311925 7% /d

none 64154 1 64153 1% /dev/shm

/dev/hda1 0 0 0 - /win

8.3.1. Стиль POSIX: statvfs() и fstatvfs()

На ранних системах Unix была только одна разновидность файловой системы. Для них было достаточно, если df считывала суперблок каждой смонтированной файловой системы, извлекала значимые сведения и красиво форматировала их для отображения. (Суперблок обычно был вторым блоком в файловой системе; первым был загрузочный блок, содержащий загрузочный код).

Однако в современном мире такой подход был бы непригодным. POSIX предоставляет расширение XSI для получения доступа к этой информации. Главная функция называется statvfs() («vfs» часть происходит от лежащей в основе технологии SunOS, использованной позже в System V Release 4, которая называется виртуальной файловой системой.) Имеется две функции:

#include <sys/types.h> /* XSI */

#include <sys/statvfs.h>


int statvfs(const char *path, struct statvfs *buf);

int fstatvfs(int fd, struct statvfs *buf);

statvfs() использует для любого файла имя пути; она возвращает сведения о файловой системе, содержащей файл. fstatvfs() принимает в качестве первою аргумента дескриптор открытого файла, здесь также возвращается информация о файловой системе, содержащей открытый файл, struct statvfs содержит следующие члены:

struct statvfs {

 unsigned long int f_bsize;   /* Размер блока */

 unsigned long int f_frsize;

  /* Размер фрагмента («основной размер блока») */

 fsblkcnt_t f_blocks;         /* Общее число блоков */

 fsblkcnt_t f_bfree;          /* Общее число свободных блоков */

 fsblkcnt_t f_bavail;         /* Число доступных блоков (≤f_bfree) */

 fsfilcnt_t f_files;          /* Общее число индексов */

 fsfilcnt_t f_ffree;          /* Общее число свободных индексов */

 fsfilcnt_t f_favail;         /* Число доступных индексов (≤f_files) */

 unsigned long int f_fsid;    /* ID файловой системы */

 unsigned long int f_flag;    /* Флаги: ST_RDONLY и/или ST_NOSUID */

 unsigned long int f_namemax; /* Максимальная длина имени файла */

};

Сведений, которые в ней содержатся, достаточно для написания df:

unsigned long int f_bsize

Размер блока является предпочтительным размером для осуществления ввода/вывода. Файловая система пытается хранить по крайней мере f_bsize байтов стоящих данных в смежных секторах на диске. (Сектор является наименьшим количеством адресуемых данных на диске. Обычно дисковый сектор равен 512 байтам.)

unsigned long int f_frsize

Некоторые файловые системы (такие, как BSD Fast Filesystem) проводят различие между блоками и фрагментами блоков. Небольшие файлы, общий размер которых меньше размера блока, находятся в некотором числе фрагментов. Это позволяет избежать пустой потери дискового пространства (за счет допустимой цепы большей сложности кода ядра). Размер фрагмента выбирается во время создания файловой системы.

fsblkcnt_t f_blocks

Общее число блоков (в единицах f_bsize) в файловой системе.

fsblkcnt_t f_bfree

Общее число свободных блоков в файловой системе.

fsblkcnt_t f_bavail

Число блоков, которые действительно могут использоваться. Некоторые файловые системы резервируют часть блоков файловой системы для использования суперпользователем при заполнении файловой системы. Современные системы резервируют около 5 процентов, хотя это число может быть изменено администратором. (См. tune2fs(8) на системе GNU/Linux и tunefs(8) на системах Unix.)

fsfilcnt_t f_files

Общее число индексов («порядковых номеров файлов» на языке POSIX) в файловой системе. Это число обычно инициализируется и делается постоянным при создании файловой системы.

fsfilcnt_t f_ffree

Общее число свободных узлов.

fsfilcnt_t f_favail

Число индексов, которые действительно могут быть использованы. Некоторая часть индексов резервируются для суперпользователя, точно так же, как для блоков.

unsigned long int f_fsid

ID файловой системы. POSIX не определяет, что оно представляет, и это под Linux не используется.

unsigned long int f_flag

Флаги, дающие информацию о файловой системе. POSIX определяет два флага: ST_RDONLY для файловых систем только для чтения (таких, как CD-ROM) и ST_NOSUID, который запрещает использование битов setuid и setgid в исполняемых файлах. Системы GNU/Linux предусматривают дополнительные флаги: они перечислены в табл. 8.2.


Таблица 8.2. Значения GLIBC для f_flag

Флаг POSIX Значение
ST_MANDLOCK Осуществляет принудительное блокирование (см. раздел 14.2).
ST_NOATIME Не обновлять при каждом доступе время доступа
ST_NODEV Запрещает доступ через файлы устройств
ST_NODIRATIME Не обновлять поле времени доступе каталогов
ST_NOEXEC Запрещает исполнение двоичных файлов
ST_NOSUID Файловая система запрещает использование битов setuid и setgid.
ST_RDONLY Файловая система только для чтения.
ST_SYNCHRONOUS Любая запись осуществляется синхронно (см. раздел 4.6.3).

unsigned long int f_namemax

Максимальная длина имени файла. Это относится к каждому отдельному компоненту в имени пути; другими словами, максимальная длина для элемента каталога

Типы fsblkcnt_t и fsfilcnt_t определены в <sys/types.h>. Они обычно являются unsigned long, но на современных системах они могут быть даже 64-разрядными, поскольку диски стали очень большими. Следующая программа, ch08-statvfs.c, показывает, как использовать statvfs():

1  /* ch08-statvfs.с --- демонстрация statvfs */

2

3  /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */

4

5  #include <stdio.h>

6  #include <errno.h>

7  #include <mntent.h> /* для getmntent(), et al. */

8  #include <unistd.h> /* для getopt() */

9  #include <sys/types.h>

10 #include <sys/statvfs.h>

11

12 void process(const char *filename);

13 void do_statvfs(const struct mntent *fs);

14

15 int errors = 0;

16 char *myname;

17

18 /* main --- обработка опций */

19

20 int main(int argc, char **argv)

21 {

22  int c;

23  char *file = "/etc/mtab"; /* файл для чтения по умолчанию */

24

25  myname = argv[0];

26  while ((c = getopt(argc, argv, "f:")) != -1) {

27   switch (c) {

28   case 'f':

29    file = optarg;

30    break;

31   default:

32    fprintf(stderr, "usage: %s [-f fstab-file]\n", argv[0]);

33    exit(1);

34   }

35  }

36

37  process(file);

38  return (errors != 0);

39 }

40

41 /* process --- чтение структур struct mntent из файла */

42

43 void process(const char *filename)

44 {

45  FILE* fp;

46  struct mntent *fs;

47

48  fp = setmntent(filename, "r"); /* только для чтения */

49  if (fp == NULL) {

50   fprintf(stderr, "%s: %s: could not open: %s\n",

51    myname, filename, strerror(errno));

52   exit(1);

53  }

54

55  while ((fs = getmntent(fp)) != NULL)

56   do_statvfs(fs);

57

58  endmntent(fp);

59 }

Строки 1–59 в сущности те же самые, как и для ch08-mounted.c. main() обрабатывает командную стоку, a process() просматривает в цикле каждую смонтированную файловую систему. do_statvfs() осуществляет действительную работу, выводя для каждой интересующей файловой системы struct statvfs.

61  /* do_statvfs --- Использовать statvfs и вывести сведения */

62

63  void do_statvfs(const struct mntent *fs)

64  {

65   struct statvfs vfs;

66

67   if (fs->mnt_fsname[0] != '/') /* пропустить ненастоящие файловые системы */

68    return;

69

70   if (statvfs(fs->mnt_dir, &vfs) != 0) {

71    fprintf(stderr, "%s: %s: statvfs failed: %s\n",

72     myname, fs->mnt_dir, strerror(errno));

73    errors++;

74    return;

75   }

76

77   printf("%s, mounted on %s:\n", fs->mnt_dir, fs->mnt_fsname);

78   printf("\tf_bsize: %ld\n", (long)vfs.f_bsize);

79   printf("\tf_frsize: %ld\n", (long)vfs.f_frsize);

80   printf("\tf_blocks: %lu\n", (unsigned long)vfs.f_blocks);

81   printf("\tf_bfree: %lu\n", (unsigned long)vfs.f_bfree);

82   printf("\tf_bavail: %lu\n", (unsigned long)vfs.f_bavail);

83   printf("\tf_files: %lu\n", (unsigned long)vfs.f_files);

84   printf("\tf_ffree: %lu\n", (unsigned long)vfs.f_ffree);

85   printf("\tf_favail: %lu\n", (unsigned long)vfs.f_favail);

86   printf("\tf_fsid: %#lx\n", (unsigned long)vfs.f_fsid);

87

88   printf("\tf_flag: ");

89   if (vfs.f_flag == 0)

90    printf("(none)\n");

91   else {

92    if ((vfs.f_flag & ST_RDONLY) != 0)

93     printf("ST_RDONLY ");

94    if ((vfs.f_flag & ST_NOSUID) != 0)

95     printf("ST_NOSUID");

96    printf("\n");

97   }

98

99   printf("\tf_namemax: %#ld\n", (long)vfs.f_namemax);

100 }

Строки 67–68 пропускают файловые системы, которые не основываются на реальных дисковых устройствах. Это означает, что файловые системы типа /proc или /dev/pts игнорируются. (Правда, эта проверка эвристическая, но она работает: в /etc/mtab смонтированные устройства перечислены по полному пути устройства: например, /dev/hda1.) Строка 70 вызывает statvfs() с соответствующей проверкой ошибок, а строки 77-99 выводят сведения.

Строки 89–96 имеют дело с флагами: отдельные биты информации, которые присутствуют или не присутствуют. Обсуждение того, как биты флагов используются в коде С, см. во врезке. Вот вывод ch08-statvfs:

$ ch08-statvfs /* Запуск программы */

/, mounted on /dev/hda2: /* Результаты для файловой системы ext2 */

f_bsize: 4096

f_frsize: 4096

f_blocks: 1549609

f_bfree: 316663

f_bavail: 237945

f_files: 788704

f_ffree: 555482

f_favail: 555482

f_fsid: 0

f_flag: (none)

f_namemax: 255

...

/win, mounted on /dev/hda1: /* Результаты для файл. системы vfat */

f_bsize: 4096

f_frsize: 4096

f_blocks: 2092383

f_bfree: 1391952

f_bavail: 1391952

f_files: 0

f_ffree: 0

f_favail: 0

f_fsid: 0

f_flag: ST_NOSUID

f_namemax: 260

Во время написания этого, для GLIBC 2.3.2 и ранее, GNU df не использует statvfs(). Это потому, что код читает /etc/mtab и вызывает stat() для каждой смонтированной файловой системы, чтобы найти ту, номер устройства которой совпадает с соответствующим аргументом для файла (или дескриптора файла). Для того, чтобы прочесть опции монтирования, коду нужно найти файловую систему, поэтому он может установить биты f_flag. Проблема в том, что stat() на смонтированной удаленной файловой системе, сервер которой недоступен, может висеть неопределенно долго, вызвав также зависание df. С тех пор эта проблема в GLIBC была исправлена, но df не будет изменяться в течение некоторого времени, так что она сможет продолжать работать на более старых системах.

ЗАМЕЧАНИЕ. Хотя POSIX определяет statvfs() и fstatvfs(), не все системы их поддерживают или поддерживают корректно. Многие системы (включая Linux, как вскоре будет описано), имеют свои собственные системные вызовы, предоставляющие сходную информацию. GNU df использует библиотечную процедуру для получения сведений о файловой системе; исходный файл для этой процедуры наполнен #ifdef для большого числа различных систем. Со временем ситуация с переносимостью должна улучшиться.

Битовые флаги
Обычной методикой, применимой во многих случаях, является использование набора значений флагов; когда флаг установлен (т.е. true), имеет место некоторый факт или применяется некоторое условие. Значения флагов определены либо через именованные константы #define, либо через перечисления. В данной главе API nftw() (описанный далее) также использует флаги. Для поля f_flag структуры struct statvfs есть только два флага:

#define ST_RDONLY 1 /* файловая система только для чтения */

#define ST_NOSUID 2 /* setuid/setgid не разрешены */

Физически каждая именованная константа представляет различные позиции битов в значении f_flag. Логически каждое значение представляет отдельный бит информации о состоянии; т.е. некоторый факт или условие, которое является или не является истинным для данного конкретного экземпляра struct statvfs.

Флаги устанавливаются, проверяются и очищаются с помощью побитовых операторов С. Например, statvfs() устанавливает эти флаги, используя побитовый оператор ИЛИ:

int statvfs(const char *path, struct statvfs *vfs) {

 /* заполнить большую часть *vfs */

 vfs->f_flag = 0; /* Убедиться, что начинается с нуля */

 if (файловая система только для чтения)

  vfs->f_flag |= ST_RDONLY; /* Добавить флаг ST_RDONLY */

 if (файловая система запрещает setuid)

  vfs->f_flag |= ST_NOSUID; /* Добавить флаг ST_NOSUID */

 /* оставшаяся часть процедуры */

}

Побитовый оператор И проверяет, установлен ли флаг, а сочетание побитовых операторов И и дополнения очищает флаг:

if ((vfs.f_flag & ST_RDONLY) != 0) /* True, если флаг ST_RDONLY */

 vfs.f_flag &= ~(ST_RDONLY|ST_NOSUID); /* Очистить оба флага */

Побитовые операторы отпугивают, если вы не использовали их ранее. Однако, только что показанный код примера представляет обычный стиль С. Тщательно изучите каждую операцию; возможно, нарисуйте себе несколько картин, показывающих работу этих операторов. Однажды разобравшись с ними, вы можете тренировать себя, распознавая эти операторы как высокоуровневые операции для управления значениями флагов вместо их трактовки как низкоуровневых манипуляций с битами.

Причина использования флагов кроется в том, что они обеспечивают значительную экономию пространства данных. Одно поле unsigned long дает возможность хранить по меньшей мере 32 отдельных бита информации. GLIBC (на момент написания) определяет 11 различных флагов для поля f_flag.[82] Если бы вы использовали для каждого флага отдельно поле char, это потребовало бы использования 11 байтов вместо четырех, используемых unsigned long. Если бы у вас было 32 флага, это были бы 32 байта вместо четырёх!

8.3.2. Стиль Linux: statfs() и fstatfs()

Системные вызовы statfs() и fstatfs() специфичны для Linux. Их определения следующие:

#include <sys/types.h> /* GLIBC */

#include <sys/vfs.h>


int statfs(const char *path, struct statfs *buf);

int fstatfs(int fd, struct statfs *buf);

Как и в случае с statvfs() и fstatvfs(), две версии работают с именем файла или с дескриптором открытого файла соответственно, struct statfs выглядит следующим образом:

struct statfs {

 long f_type;     /* тип файловой системы */

 long f_bsize;    /* оптимальный размер блока */

 long f_blocks;   /* общее число блоков в файловой системе */

 long f_bfree;    /* число свободных блоков в ф.с. */

 long f_bavail;   /* свободные блоки, доступные пользователям */

 long f_files;    /* общее число индексов в файловой системе */

 long f_ffree;    /* свободных индексов в ф.с. */

 fsid_t f_fsid;   /* id файловой системы */

 long f_namelen;  /* максимальная длина имен файлов */

 long f_spare[6]; /* запас для дальнейшего */

};

Поля аналогичны полям в struct statvfs. По крайней мере в GLIBC 2.3.2 функции POSIX statvfs() и fstatvfs() являются оболочками вокруг statfs() и fstatfs() соответственно, копируя значения из одной разновидности структуры в другую.

Преимуществом использования statfs() или fstatfs() является то, что они системные вызовы. Ядро возвращает информацию непосредственно. Поскольку нет поля f_flag с опциями монтирования, нет необходимости просматривать каждую смонтированную файловую систему для нахождения нужной. (Другими словами, для заполнения опций монтирования statfvs() должна проверить каждую смонтированную файловую систему, чтобы найти содержащую файл, имя которого содержится в path или fd. Функция statfs() не нуждается в этом, поскольку она не предоставляет сведений об опциях монтирования.)

Есть два неудобства в использовании этих вызовов. Во-первых, они специфичны для Linux. Во-вторых, часть сведений из struct statvfs отсутствует в struct statfs, наиболее значительными из них являются флаги (f_flag) и число доступных индексов (f_favail). (Поэтому statvfs() Linux приходится находить опции монтирования из других источников, таких, как /etc/mtab, и она «фабрикует» информацию для тех полей struct statvfs, для которых действительные сведения недоступны.)

Одно поле struct statfs заслуживает особого замечания. Это поле f_type, указывающее тип файловой системы. Значение является магическим числом файловой системы, извлеченной из суперблока. Справочная страница statfs(2) предоставляет список обычно используемых файловых систем и их магические числа, которые мы используем в ch08-statfs.c. (Увы, отдельного файла #include нет.)

1   /* ch08-statfs.с --- демонстрация statfs Linux */

2

3   /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */

4

5   #include <stdio.h>

6   #include <errno.h>

7   #include <mntent.h> /* для getmntent() и др. */

8   #include <unistd.h> /* для getopt() */

9   #include <sys/types.h>

10  #include <sys/vfs.h>

11

12  /* Определения взяты из справочной страницы для statfs(2): */

13  #define AFFS_SUPER_MAGIC     0xADFF

14  #define EFS_SUPER_MAGIC      0x00414A53

15  #define EXT_SUPER_MAGIC      0x137D

16  #define EXT2_OLD_SUPER_MAGIC 0xEF51

17  #define EXT2_SUPER_MAGIC     0xEF53

18  #define HPFS_SUPER_MAGIC     0xF995E849

19  #define ISOFS_SUPER_MAGIC    0x9660

20  #define MINIX_SUPER_MAGIC    0x137F /* оригинальный minix */

21  #define MINIX_SUPER_MAGIC2   0x138F /* 30-симв. minix */

22  #define MINIX2_SUPER_MAGIC   0x2468 /* minix V2 */

23  #define MINIX2_SUPER_MAGIC2  0x2478 /* minix V2, имена 30 симв. */

24  #define MSDOS_SUPER_MAGIC    0x4d44

25  #define NCP_SUPER_MAGIC      0x564c

26  #define NFS_SUPER_MAGIC      0x6969

27  #define PROC_SUPER_MAGIC     0x9fa0

28  #define SMB_SUPER_MAGIC      0x517B

29  #define XENIX_SUPER_MAGIC    0x012FF7B4

30  #define SYSV4_SUPER_MAGIC    0x012FF7B5

31  #define SYSV2_SUPER_MAGIC    0x012FF7B6

32  #define COH_SUPER_MAGIC      0x012FF7B7

33  #define UFS_MAGIC            0x00011954

34  #define XFS_SUPER_MAGIC      0x58465342

35  #define _XIAFS_SUPER_MAGIC   0x012FD16D

36

37  void process(const char *filename);

38  void do_statfs(const struct mntent *fs);

39

40  int errors = 0;

41  char *myname;

42

    /* ...main() без изменений, process() почти идентична... */

85

86  /* type2str --- преобразование типа fs в строку из statfs(2) */

87

88  const char *type2str(long type)

89  {

90   static struct fsname {

91    long type;

92    const char *name;

93   } table[] = {

94    { AFFS_SUPER_MAGIC, "AFFS" },

95    { COH_SUPER_MAGIC, "COH" },

96    { EXT2_OLD_SUPER_MAGIC, "OLD EXT2" },

97    { EXT2_SUPER_MAGIС, "EXT2" },

98    { HPFS_SUPER_MAGIC, "HPFS" },

99    { ISOFS_SUPER_MAGIC, "ISOFS" },

100   { MINIX2_SUPER_MAGIC, "MINIX V2" },

101   { MINIX2_SUPER_MAGIC2, "MINIX V2 30 char" },

102   { MINIX_SUPER_MAGIC, "MINIX" },

103   { MINIX_SUPER_MAGIC2, "MINIX 30 char" },

104   { MSDOS_SUPER_MAGIC, "MSDOS" },

105   { NCP_SUPER_MAGIС, "NCP" },

106   { NFS_SUPER_MAGIC, "NFS" },

107   { PROC_SUPER_MAGIC, "PROC" },

108   { SMB_SUPER_MAGIC, "SMB" },

109   { SYSV2_SUPER_MAGIC, "SYSV2" },

110   { SYSV4_SUPER_MAGIC, "SYSV4" },

111   { UFS_MAGIC, "UFS" },

112   { XENIX_SUPER_MAGIC, "XENIX" },

113   { _XIAFS_SUPER_MAGIC, "XIAFS" },

114   { 0, NULL },

115  };

116  static char unknown[100];

117  int i;

118

119  for (i = 0; table[i].type != 0; i++)

120   if (table[i].type == type)

121    return table[i].name;

122

123  sprintf(unknown, "unknown type: %#x", type);

124  return unknown;

125 }

126

127 /* do_statfs --- Использовать statfs и вывести сведения */

128

129 void do_statfs(const struct mntent *fs)

130 {

131  struct statfs vfs;

132

133  if (fs->mnt_fsname[0] != '/') /* пропустить фиктивные файловые системы */

134   return;

135

136  if (statfs(fs->mnt_dir, &vfs) != 0) {

137   fprintf(stderr, "%s: %s: statfs failed: %s\n",

138    myname, fs->mnt_dir, strerror(errno));

139   errors++;

140   return;

141  }

142

143  printf("%s, mounted on %s:\n", fs->mnt_dir, fs->mnt_fsname);

144

145  printf("\tf_type: %s\n", type2str(vfs.f_type));

146  printf("\tf_bsize: %ld\n", vfs.f_bsize);

147  printf("\tf_blocks: %ld\n", vfs.f_blocks);

148  printf("\tf_bfree: %ld\n", vfs.f_bfree);

149  printf("\tf_bavail: %ld\n", vfs.f_bavail);

150  printf("\tf_files: %ld\n", vfs.f_files);

151  printf("\tf_ffree: %ld\n", vfs.f_ffree);

152  printf("\tf_namelen: %ld\n", vfs.f_namelen);

153 }

Чтобы сохранить место, мы опустили main(), которая не изменилась с представленной ранее другой программы, мы также опустили process (), которая теперь вызывает do_statfs() вместо do_statvfs().

Строки 13–35 содержат список магических чисел файловых систем из справочной страницы statfs(2). Хотя эти числа можно получить из заголовочных файлов исходного кода ядра, это трудно (мы пробовали), а показанному здесь способу представления следовать легче. Строки 86–125 определяют type2str(), которая преобразует магическое число в выводимую строку. Она осуществляет простой линейный поиск в таблице пар (значение, строка). В (маловероятном) случае, когда магическое число в таблице отсутствует, type2str() создает сообщение «неизвестный тип» и возвращает его (строки 123–124).

do_statfs() (строки 129–153) выводит сведения из struct statfs. Член f_fsid опущен, поскольку fsid_t является непрозрачным типом. Код прост; строка 145 использует type2str() для вывода типа файловой системы. Как для сходной программы, использующей statvfs(), эта функция игнорирует файловые системы, которые не расположены на локальных устройствах (строки 133–134). Вот вывод на нашей системе:

$ ch08-statfs /* Запуск программы */

/, mounted on /dev/hda2: /* Результаты для файловой системы ext2 */

f_type: ЕХТ2

f_bsize: 4096

f_blocks: 1549609

f_bfrее: 316664

f_bavail: 237946

f_files: 788704

f_ffree: 555483

f_namelen: 255

...

/win, mounted on /dev/hda1: /* Результаты для файловой с-мы vfat */

f_type: MSDOS

f_bsize: 4096

f_blocks: 2092383

f_bfree: 1391952

f_bavail: 1391952

f_files: 0

f_ffree: 0

f_namelen: 260

В заключение, использование statvfs() или statfs() в вашем собственном коде зависит от ваших потребностей. Как описано в предыдущем разделе, GNU df не использует statvfs() под GNU/Linux и в общем имеет тенденцию использовать уникальный для каждой Unix-системы системный вызов «получения сведений о файловой системе». Хотя это работает, это не очень привлекательно. С другой стороны, иногда у вас нет выбора: например, проблемы GLIBC, о которых мы упоминали выше. В этом случае нет безупречного решения.

8.4. Перемещение по иерархии файлов

Несколько системных вызовов и стандартных библиотечных функций дают возможность изменять текущий каталог и определять полный путь к текущему каталогу. Более сложные функции позволяют осуществлять произвольные действия с каждым объектом файловой системы в иерархии каталогов.

8.4.1. Смена каталога: chdir() и fchdir()

В разделе 1.2 «Модель процессов Linux/Unix» мы говорили:

Текущим каталогом является каталог, относительно которого отсчитываются относительные пути (те, которые не начинаются с /). Это каталог, «в» котором вы находитесь, когда даете оболочке команду 'cd некоторое_место'.

У каждого процесса есть текущий рабочий каталог. Каждый новый процесс наследует свой текущий каталог от процесса, который его запустил (своего родителя). Две функции позволяют перейти в другой каталог:

#include <unistd.h>


int chdir(const char *path); /* POSIX */

int fchdir(int fd); /* XSI */

Функция chdir() принимает строку с названием каталога, тогда как fchdir() ожидает дескриптор файла, который был открыт для каталога с помощью open().[83] Обе возвращают 0 при успехе и -1 при ошибке (с errno, установленной соответствующим образом). Обычно, если open() для каталога завершается успешно, fchdir() также достигает цели, если кто-то не изменил права доступа к каталогу между вызовами, (fchdir() сравнительно новая функция; на старых системах Unix ее нет.)

Использование этих функций почти тривиально. Следующая программа, ch08-chdir.c, демонстрирует обе функции. Она демонстрирует также, что fchdir() может потерпеть неудачу, если права доступа открытого каталога не включают доступа на поиск (исполнение).

1  /* ch08-chdir.c --- демонстрация chdir() и fchdir().

2     Для краткости проверка ошибок опущена */

3

4  #include <stdio.h>

5  #include <fcntl.h>

6  #include <unistd.h>

7  #include <sys/types.h>

8  #include <sys/stat.h>

9

10 int main(void)

11 {

12  int fd;

13  struct stat sbuf;

14

15  fd = open(".", O_RDONLY); /* открыть каталог для чтения */

16  fstat(fd, &sbuf); /* получить сведения, нужны начальные права доступа */

17  chdir(".."); /* 'cd ..' */

18  fchmod(fd, 0); /* отменить права доступа каталога */

19

20  if (fchdir(fd) < 0) /* попытаться выполнить 'cd' обратно, должно завершиться неудачей */

21   perror("fchdxr back");

22

23  fchmod(fd, sbuf.st_mode & 07777); /* восстановить первоначальные права доступа */

24  close(fd); /* все сделано */

25

26  return 0;

27 }

Строка 15 открывает текущий каталог. Строка 16 вызывает fstat() для открытого каталога, так что мы получаем копию его прав доступа. Строка 17 использует chdir() для перемещения на один уровень в иерархии файлов. Строка 18 выполняет грязную работу, отменяя все права доступа первоначального каталога.

Строки 20–21 пытаются перейти обратно в первоначальный каталог. Ожидается, что эта попытка будет безуспешной, поскольку текущие права доступа не позволяют это. Строка 23 восстанавливает первоначальные права доступа, 'sbuf.st_mode & 07777' получает младшие 12 битов прав доступа; это обычные 9 битов rwxrwxrwx и биты setuid, setgid и «липкий» бит, которые мы обсудим в главе 11 «Права доступа и ID пользователя и группы». Наконец, строка 24 заканчивает работу, закрывая открытый дескриптор файла. Вот что происходит при запуске программы.

$ ls -ld . /* Показать текущие права доступа */

drwxr-xr-x 2 arnold devel 4096 Sep 9 16:42 .

$ ch08-chdir /* Запустить программу */

fchdir back: Permission denied /* Ожидаемая неудача */

$ ls -ld . /* Снова посмотреть на права доступа */

drwxr-xr-x 2 arnold devel 4096 Sep 9 16:42 /* Все восстановлено как раньше */

8.4.2. Получение текущего каталога: getcwd()

Названная должным образом функция getcwd() получает абсолютный путь текущего рабочего каталога.

#include <unistd.h> /* POSIX */

char *getcwd(char *buf, size_t size);

Функция заносит в buf путь; ожидается, что размер buf равен size байтам. При успешном завершении функция возвращает свой первый аргумент. В противном случае, если требуется более size байтов, она возвращает NULL и устанавливает в errno ЕRANGE. Смысл в том, что если случится ERANGE, следует попытаться выделить буфер большего размера (с помощью malloc() или realloc()) и попытаться снова.

Если любой из компонентов каталога, ведущих к текущему каталогу, не допускает чтения или поиска, getcwd() может завершиться неудачей, а errno будет установлен в EACCESS. Следующая простая программа демонстрирует ее использование:

/* ch08-getcwd.c --- демонстрация getcwd().

Проверка ошибок для краткости опущена */

#include <stdio.h>

#include <fcntl.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/stat.h>


int main(void) {

 char buf[PATH_MAX];

 char *cp;

 cp = getcwd(buf, sizeof(buf));

 printf("Current dir: %s\n", buf);

 printf("Changing to ..\n");

 chdir(".."); /* 'cd ..' */

 cp = getcwd(buf, sizeof(buf));

 printf("Current dir is now: %s\n", buf);

 return 0;

}

Эта простая программа выводит текущий каталог, переходит в родительский каталог, затем выводит новый текущий каталог. (Переменная cp здесь на самом деле не нужна, но в реальной программе она была быиспользована для проверки ошибок). При запуске программа создает следующий вывод:

$ ch08-getcwd

Current dir: /home/arnold/work/prenhall/progex/code/ch08

Changing to ..

Current dir is now: /home/arnold/work/prenhall/progex/code

Формально, если аргумент buf равен NULL, поведение getcwd() не определено. В данном случае версия GLIBC getcwd() вызовет malloc() за вас, выделяя буфер с размером size. Идя даже дальше, если size равен 0, выделяется «достаточно большой» буфер для вмещения возвращенного имени пути. В любом случае вы должны вызвать для возвращенного указателя free() после завершения работы с буфером.

Поведение GLIBC полезно, но не переносимо. Для кода, который должен работать на разных платформах, вы можете написать замещающую функцию, которая предоставляет те же самые возможности, в то же время заставив ее непосредственно вызывать getcwd() на системе с GLIBC.

Системы GNU/Linux предоставляют файл /proc/self/cwd. Этот файл является символической ссылкой на текущий каталог:

$ cd /tmp /* Сменить каталог */

$ ls -l /рroc/self/cwd /* Посмотреть на файл */

lrwxrwxrwx 1 arnold devel 0 Sep 9 17:29 /proc/self/cwd -> /tmp

$ cd /* Перейти в домашний каталог */

$ ls -l /proc/self/cwd /* Снова посмотреть на него */

lrwxrwxrwx 1 arnold devel 0 Sep 9 17:30 /proc/self/cwd -> /home/arnold

Это удобно на уровне оболочки, но представляет проблему на уровне программирования. В частности, размер файла равен нулю! (Это потому, что это файл в /proc, который продуцирует ядро; это не настоящий файл, находящийся на диске.)

Почему нулевой размер является проблемой? Если вы помните из раздела 5.4.5 «Работа с символическими ссылками», lstat() для символической ссылки возвращает в поле st_size структуры struct stat число символов в имени связанного файла. Это число может затем использоваться для выделения буфера соответствующего размера для использования с readlink(). Здесь это не будет работать, поскольку размер равен нулю. Вам придется использовать (или выделять) буфер, который, как вы полагаете, достаточно большой. Однако, поскольку readlink() не выдает символов больше, чем вы предоставили места, невозможно сказать, достаточен буфер или нет; readlink() не завершается неудачей, когда недостаточно места. (См. в разделе 5.4.5 «Работа с символическими ссылками» функцию Coreutils xreadlink(), которая решает проблему.)

В дополнение к getcwd() GLIBC имеет несколько других непереносимых процедур. Они избавляют вас от хлопот по управлению буферами и обеспечивают совместимость со старыми системами BSD. Подробности см в getcwd(3).

8.4.3. Перемещение по иерархии: nftw()

Обычной задачей программирования является обработка целых иерархий каталогов: выполнение действий над каждым файлом и каждым каталогом и подкаталогом в целостном дереве. Рассмотрите, например, команду du, которая выводит сведения об использовании диска, 'chown -R', которая рекурсивно изменяет владельцев, или программу find, которая находит файлы, подходящие по определенным критериям.

На данный момент вы знаете достаточно, чтобы написать собственный код для открывания и чтения каталогов вручную, вызова stat() (или lstat()) для каждого элемента и рекурсивной обработки подкаталогов. Однако, такой код трудно сделать правильным; можно выйти за пределы дескрипторов файлов, если вы будете оставлять родительские каталоги открытыми при обработке подкаталогов; нужно решить, обрабатывать ли символические ссылки как таковые или как файлы, на которые они указывают; нужно суметь справиться с каталогами, которые недоступны для чтения или поиска и т.д. Также трудно писать один и тот же код снова и снова, когда он требуется в нескольких приложениях.

8.4.3.1. Интерфейс nftw()

Чтобы избавиться от проблем, System V предложила функцию ftw() («file tree walk» — обход дерева файлов), ftw() осуществляла всю работу по «прохождению» дерева (иерархии) файлов. Вы предоставляете ей указатель на функцию, и она вызывает эту функцию для каждого объекта файла, с которым сталкивается. Ваша функция должна затем обработать каждый объект файловой системы, как считает нужным.

Со временем стало ясно, что интерфейс ftw() не вполне выполнял свою работу;[84] например, первоначально он не поддерживал символические ссылки. По этим причинам к X/Open Portability Guide, который теперь является частью POSIX, была добавлена nftw() («new (новая) ftw()» [важно]). Вот прототип:

#include <ftw.h> /* XSI */


int nftw(const char *dir,    /* Отправная точка */

 int (*fn)(const char *file, /* Указатель функции на */

  const struct stat *sb,     /* функцию из четырех аргументов */

  int flag, struct FTW *s),

 int depth, int flags);      /* Максимум открытых fds, флаги */

А вот аргументы:

const char *dir

Строка с именем отправной точки иерархии для обработки.

int (*fn)(const char *file, const struct stat *sb, int flag, struct FTW *s)

Указатель на функцию с данными аргументами. Эта функция вызывается для каждого объекта в иерархии. Подробности ниже.

int depth

Этот аргумент назван неверно. Чтобы избежать выхода за пределы дескрипторов файлов, nftw() держит открытыми не более, чем depth одновременно открытых каталогов. Это не препятствует обработке nftw() иерархий, которые глубже уровня depth, но меньшие значения depth означают, что nftw() придется делать больше работы.

flags

Набор флагов, объединяемых побитовым ИЛИ, которые указывают, как nftw() должна обрабатывать иерархию.

Интерфейс nftw() имеет два отдельных набора флагов. Одни набор контролирует саму nftw() (аргумент flags функции nftw()). Другой набор передается предоставленной пользователем функции, которую вызывает nftw() (аргумент flags для (*fn)()). Однако, интерфейс запутывает, поскольку имена обоих наборов флагов начинаются с префикса 'FTW_'. Мы постараемся сделать все, чтобы это прояснить по ходу дела. В табл. 8.3 представлены флаги, которые контролируют nftw().


Таблица 8.3. Управляющие флаги для nftw()

Флаг Значение
FTW_CHDIR При установке перед открытием каждого из каталогов сначала осуществляется переход в него. Это действие более эффективно, но вызывающее приложение должно быть готово оказаться в другом каталоге, когда nftw() завершится
FTW_DEPTH При установке осуществляется «сначала глубокий поиск». Это означает, что все файлы и подкаталоги обрабатываются до того, как будет обработан сам каталог
FTW_MOUNT При установке остается в той же самой смонтированной файловой системе. Это более специализированная опция
FTW_PHYS При установке не следует по символическим ссылкам
FTW_CHDIR предоставляет большую эффективность; при обработке глубоких иерархий файлов ядру не приходится обрабатывать снова и снова полные пути имен при осуществлении stat() или открытии каталога. Экономия времени для больших иерархий может быть вполне ощутимой.[85]

FTW_DEPTH может быть, а может и не быть тем, что вам нужно; для некоторых приложений это безусловно справедливо. Рассмотрите 'chmod -R u-rx .'. Эта команда удаляет права чтения и исполнения для владельца для всех файлов и подкаталогов в текущем каталоге. Если это изменение прав доступа применено к каталогу до того, как оно применено к содержимому каталога, любые последующие попытки обработки содержимого потерпят неудачу! Поэтому команда должна применяться к каталогу после обработки его содержимого.[86] Справочная страница GNU/Linux nftw(3) отмечает для FTW_PHYS, что «это то, что вам нужно». Это позволяет вам обрабатывать сами символические ссылки, что обычно бывает нужно (Рассмотрите du, она должна подсчитывать занимаемое ссылками пространство отдельно от связанных с ними файлов.)

8.4.3.2. Функция обратного вызова nftw()

После запуска nftw() она вызывает функцию, указатель для которой предоставляете вы. (Такие функции называются функциями обратного вызова (callback functions), поскольку они «вызываются обратно» из библиотечного кода.) Функция обратного вызова получает четыре аргумента:

const char *file

Имя текущего обрабатываемого файла (каталога, символической ссылки и т.д.).

const struct stat *sb

Указатель на struct stat для файла.

int flag

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

struct FTW *s

Эта структура предоставляет две отдельные части информации:

struct FTW {

 int base;  /* Индекс в файле базовой части имени файла */

 int level; /* Глубина этого элемента относительно точки отсчета */

};

Параметр flag имеет одно из перечисленных в табл. 8.4 значений.


Таблица 8.4. Значения флагов для функции обратного вызова nftw()

Флаг Значение
FTW_F Объект является обычным файлом
FTW_D Объект является каталогом
FTW_DNR Объект является каталогом, который нельзя прочесть
FTW_SL Объект является символической ссылкой
FTW_NS Объект не является символической ссылкой, а stat() потерпела неудачу
FTW_DP Объект является каталогом, элементы которого были уже обработаны. Это может случиться, лишь когда в вызове nftw() использовался FTW_DEPTH
FTW_SLN Объект является символической ссылкой, указывающей на несуществующий файл. Это может случиться, лишь когда в вызове nftw() не используется FTW_PHYS
struct FTW* s предоставляет дополнительную информацию, которая может быть полезной. s->base действует в качестве индекса в file; file является полным путем обрабатываемого объекта (относительно точки отсчета), 'file + s->base' указывает на первый символ компонента имени файла.

s->level указывает текущую глубину иерархии; считается, что первоначальная точка отсчета находится на уровне 0.

Функция обратного вызова должна вернуть 0, если все нормально. Любое ненулевое возвращенное значение заставляет nftw() прекратить свою обработку и вернуть то самое ненулевое значение. Справочная страница отмечает, что функция обратного вызова должна останавливать обработку только путем возвращаемого значения, чтобы у nftw() был шанс произвести очистку: т.е. освободить динамически выделенную память, закрыть открытые дескрипторы файлов и т.д. Функции обратного вызова не следует использовать longjmp(), если только программа не завершается немедленно, (longjmp() является продвинутой функцией, которую мы опишем в разделе 12.5 «Нелокальные goto».) Рекомендуемой методикой обработки ошибок является установка глобальной переменной, указывающей на наличие проблем, возвращение 0 из функции обратного вызова и обработка ошибок после завершения перемещения nftw() по иерархии файлов. (GNU du это делает, как мы вскоре увидим.)

Давайте свяжем все это воедино в примере программы. ch08-nftw.c обрабатывает каждый файл или каталог, указанный в командной строке, запуская для них nftw(). Функция, обрабатывающая каждый файл, выводите отступом имя и тип файла, показывая иерархическое положение каждого файла. Для разнообразия мы сначала покажем результаты, а затем покажем и обсудим программу:

$ pwd /* Где мы находимся */

/ home/аrnold/work/prenhall/progex

$ code/ch08/ch08-nftw code /* Обойти каталог 'code' */

code (directory) /* Каталог верхнего уровня */

  ch02 (directory) /* Подкаталоги с отступом на один уровень */

    ch02-printenv.c (file) /* Файлы в подкаталоге с отступом

                              на два уровня */

  ch03 (directory)

    ch03-memaddr.c (file)

  ch04 (directory)

    ch04-holes.c (file)

    ch04-cat.с (file)

    ch04-maxfds.c (file)

    v7cat.c (file)

...

Вот сама программа:

1  /* ch08-nftw.c --- демонстрирует nftw() */

2

3  #define _XOPEN_SOURCE 1 /* Требуется под GLIBC для nftw() */

4  #define _XOPEN_SOURCE_EXTENDED 1 /* To же */

5

6  #include <stdio.h>

7  #include <errno.h>

8  #include <getopt.h>

9  #include <ftw.h> /* получает для нас <sys/types.h> и <sys/stat.h> */

10 #include <limits.h> /* для PATH_MAX */

11 #include <unistd.h> /* для объявлений getdtablesize(), getcwd() */

12

13 #define SPARE_FDS 5 /* fds для использования другими функциями, см. текст */

14

15 extern int process(const char *file, const struct stat *sb,

16  int flag, struct FTW *s);

17

18 /* usage --- print message and die */

19

20 void usage(const char *name)

21 {

22  fprintf(stderr, "usage: %s (-c) directory ...\n", name);

23  exit(1);

24 }

25

26 /* main --- вызвать nftw() для каждого аргумента командной строки */

27

28 int main(int argc, char **argv)

29 {

30  int i, c, nfds;

31  int errors = 0;

32  int flags = FTW_PHYS;

33  char start[PATH_MAX], finish[PATH_MAX];

34

35  while ((c = getopt(argc, argv, "с")) != -1) {

36   switch (c) {

37   case 'c':

38    flags |= FTW_CHDIR;

39    break;

40   default:

41    usage(argv[0]);

42    break;

43   }

44  }

45

46  if (optind == argc)

47   usage(argv[0]);

48

49  getcwd(start, sizeof start);

50

51  nfds = getdtablesize() - SPARE_FDS; /* оставить несколько запасных дескрипторов */

52  for (i = optind; i < argc; i++) {

53   if (nftw(argv[i], process, nfds, flags) != 0) {

54    fprintf(stderr, "%s: %s: stopped early\n",

55     argv[0], argv[i]);

56    errors++;

57   }

58  }

59

60  if ((flags & FTW_CHDIR) != 0) {

61   getcwd(finish, sizeof finish);

62   printf("Starting dir: %s\n", start);

63   printf("Finishing dir: %s\n", finish);

64  }

65

66  return (errors != 0);

67 }

Строки 3–11 включают заголовочные файлы. По крайней мере в GLIBC 2.3.2 перед включением любого заголовочного файла необходимы #define для _XOPEN_SOURCE и _XOPEN_SOURCE_EXTENDED. Они дают возможность получить объявления и значения флагов, которые nftw() предоставляет свыше предоставляемых ftw(). Это специфично для GLIBC. Потребность в этом в конечном счете исчезнет, когда GLIBC станет полностью совместимой со стандартом POSIX 2001.

Строки 35–44 обрабатывают опции. Опция добавляет к флагам nftw() FTW_CHDIR. Это эксперимент с целью увидеть, сможете ли вы оказаться где-то в другом месте от того, где начинали. Кажется, это возможно, если nftw() завершается неудачей, в противном случае вы заканчиваете там же, где начинали. (POSIX не документирует это явным образом, но целью, похоже, было действительно заканчивать там же, где начинали. Стандарт не говорит, что функция обратного вызова не должна менять текущий каталог.)

Строка 49 сохраняет начальный каталог для дальнейшего использования, пользуясь getcwd().

Строка 51 вычисляет число дескрипторов, которые может использовать nftw(). Мы не хотим, чтобы она использовала все доступные дескрипторы файлов, если функция обратного вызова также хочет открывать файлы. В вычислении используется getdtablesize() (см. раздел 4.4.1 «Понятие о дескрипторах файлов») для получения максимально возможного числа и вычета из него SPARE_FDS, который был вычислен ранее в строке 13.

Эта процедура служит основанием для больших объяснений. В обычном случае по крайней мере три дескриптора уже используются для стандартного ввода, стандартного вывода и стандартной ошибки. nftw() нужно некоторое количество дескрипторов файлов для открытия и чтения каталогов; внутри себя opendir() использует open() при открытии каталогов для чтения. Если функции обратного вызова также нужно открывать файлы, мы должны предотвратить израсходование функцией nftw() всех доступных дескрипторов файлов для открывания каталогов. Мы делаем это, вычитая некоторое число из максимально допустимого. Для данного примера мы выбрали пять, но если функции обратного вызова нужно открывать файлы, должно использоваться большее число, (nftw() знает, как восстановиться при израсходовании дескрипторов файлов; мы не должны беспокоиться о таком случае.)

Строки 52–58 являются главным циклом над нашими аргументами; строки 53–57 проверяют ошибки; когда они появляются, код выводит диагностическое сообщение и увеличивает значение переменной errors.

Строки 60–64 являются частью эксперимента с FTW_CHDIR, выводящего начальный и конечный каталоги, если было использовано .

По-настоящему интересной функцией является process(); это функция обратного вызова, которая обрабатывает каждый файл. Она использует базовый шаблон для функции обратного вызова nftw(), который является оператором switch для значения flag.

69  /* process --- выводит каждый файл на нужном уровне */

70

71  int process(const char "file, const struct stat *sb,

72  int flag, struct FTW *s)

73  {

74   int retval = 0;

75   const char *name = file + s->base;

76

77   printf("%*s", s->level * 4, ""); /* сделать отступ */

78

79   switch (flag) {

80   case FTW_F:

81    printf("%s (file)\n", name);

82    break;

83   case FTW_D:

84    printf("%s (directory)\n", name);

85    break;

86   case FTW_DNR:

87    printf("%s (unreadable directory)\n", name);

88    break;

89   case FTW_SL:

90    printf("%s (symbolic link)\n", name);

91    break;

92   case FTW_NS:

93    printf("%s (stat failed): %s\n", name, strerror(errno));

94    break;

95   case FTW_DP:

96   case FTW_SLN:

97    printf("%s: FTW_DP or FTW_SLN: can't happen'\n", name);

98    retval = 1;

99    break;

100  default:

101   printf("%s: unknown flag %d: can't happen'\n", name, flag);

102   retval = 1;

103   break;

104  }

105

106  return retval;

107 }

Строка 75 использует 'file + s->base' для получения имени из полного пути. Это значение указателя сохраняется в переменной name для повторного использования в функции.

Строка 77 делает отступ нужного размера, используя красивый трюк. Используя %*s, printf() получает от первого аргумента ширину поля. Это вычисляется динамически как 'level * 4'. Строка, которая должна быть выведена — «», пустая строка. Конечным результатом является то, что printf() создает для нас отступ нужного размера без необходимости запуска цикла.

Строки 79–104 являются оператором switch. В данном случае он не делает ничего весьма интересного, кроме вывода имени файла и его типа (файл, каталог и т.д.)

Хотя эта программа не использует struct stat, должно быть ясно, что вы могли бы сделать в функции обратного вызова все, что хотите.

ЗАМЕЧАНИЕ. Джим Мейеринг (Jim Meyering), сопроводитель GNU Coreutils, замечает, что дизайн nftw() несовершенен из-за ее рекурсивной природы. (Она рекурсивно вызывает себя при обработке подкаталогов.) Если иерархия каталогов становится действительно глубокой, в диапазоне уровней 20 000–40 000 (!), nftw() может выйти за пределы размера стека, уничтожив программу. Есть также и другие проблемы, связанные с дизайном nftw(). Версия GNU Coreutils после 5.0 исправляет это путем использования набора процедур fts() (см. fts(3)).

8.5. Обход дерева файлов: GNU du

GNU версия du в GNU Coreutils использует nftw() для обхода одной или более иерархии файлов, собирая и выводя сведения, касающиеся количества используемого дискового пространства. У нее большое число опций, которые управляют ее поведением но отношению к символическим ссылкам, форматом вывода чисел и т.д. Это делает разбор кода труднее, чем могло бы быть при более простой версии. (Однако, мы не собираемся позволить этому остановить нас.) Вот сводка опций du, которые вскоре будут полезны, когда мы рассмотрим код.

$ du --help

Usage: du [OPTION]... [FILE]...

  Дает сводку использования диска для каждого FILE,

  рекурсивно для каталогов.

  Обязательные для длинных опций аргументы являются обязательными

  также и для коротких опций.

-a,  --all              записать число всех файлов, а не только

                        каталогов

     --apparent-size    вывести видимые размеры, а не использование

                        диска; хотя видимый размер обычно меньше, он

                        может быть и больше из-за дыр в файлах,

                        внутренней фрагментации, косвенных блоков и т.п.

-В,  --block-size=SIZE  использовать блоки размером SIZE байтов

-b,  --bytes            эквивалентно '--apparent-size --block-size=1'

-с,  --total            выводит итоговую сумму

-D,  --dereference-args разыменовывать FILE, которые являются

                        символическими ссылками

-h,  --human-readable   вывести размеры в удобном для восприятия

                        формате (например, 1K 234М 2G)

-Н,  --si               так же, но использовать степени 1000, не 1024

-k                      подобно --block-size=1K

-l,  --count-links      считать размеры несколько раз при прямых

                        ссылках

-L,  --dereference      разыменовывать все символические ссылки

-S,  --separate-dirs    не включать размер подкаталогов

-s,  --summarize        отобразить для каждого аргумента лишь итоги

-х,  --one-file-system  пропускать каталоги на различных файловых

                        системах

-X   --exclude-         исключить файлы, подходящие под любой

FILE from=FILE          образец в FILE

     --exclude=PATTERN  исключить файлы, соответствующие PATTERN

     --max-depth=N      вывести итог для каталога (или файла, с --all)

                        только если он находится на N или менее уровней

                        глубже аргумента командной строки;

     --max-depth=0      то же самое, что и --summarize

     --help             отобразить экран справки и выйти

     --version          вывести сведения о версии и выйти

SIZE может быть (или может быть целым, за которым

может следовать это) одним из

следующих: kB 1000, K 1024, MB 1 000 000, M 1 048 576 и т.д.

для G, T, Р, E, Z, Y.

Чтобы еще больше усложнить дело, du использует частную версию nftw(), у которой есть несколько расширений. Сначала имеются дополнительные значения флагов для функции обратного вызова:

FTW_DCHP

Это значение означает, что nftw() не может выполнять 'chdir("..")'.

FTW_DCH

Это значение означает, что nftw() не может использовать chdir() для перехода в сам каталог.

FTW_DPRE

Частная nftw() вызывает для каталогов функцию обратного вызова дважды. Это значение используется при первой встрече с каталогом. После обработки всех нижележащих объектов каталога используется стандартное значение FTW_DP.

Частная nftw() добавляет также в struct FTW новый член, int skip. Если текущий объект является каталогом и функция обратного вызова устанавливает в поле skip ненулевое значение, nftw() не будет больше обрабатывать этот каталог. (Функция обратного вызова должна установить skip таким образом, когда flag равен FTW_DPRE; делать это для FTW_DP слишком поздно.)

С этим объяснением за поясом, вот функция process_file() из du.c. Номера строк приведены относительно начала функции:

1  /* Эта функция вызывается один раз для каждого объекта файловой

2     системы, с которой сталкивается nftw. nftw осуществляет сначала

3     поиск вглубь. Эта функция знает это и собирает итоги для каталогов

4     на основе изменений в глубине текущего элемента. */

5

6  static int

7  process_file(const char *file, const struct stat *sb,

8   int file_type, struct FTW *info)

9  {

10  uintmax_t size;

11  uintmax_t size_to_print;

12  static int first_call = 1;

13  static size_t prev_level;

14  static size_t n_alloc;

15  static uintmax_t *sum_ent;

16  static uintmax_t *sum_subdir;

17  int print = 1;

18

19  /* Всегда определяйте info->skip перед возвратом. */

20  info->skip = excluded_filename(exclude, file + info->base);

    /* Для --exclude */

Эта функция делает многое, поскольку ей приходится реализовать все опции du. Строка 17 устанавливает print в true (1); по умолчанию выводятся сведения о каждом файле. Дальнейший код устанавливает ее при необходимости в false (0).

Строка 20 устанавливает info->skip на основе опции --exclude. Обратите внимание, что это исключает подкаталоги, если каталог совпадает с шаблоном для --exclude.

22 switch (file_type)

23 {

24 case FTW_NS:

25  error (0, errno, _("cannot access %s"), quote(file));

26  G_fail = 1; /* Установить глобальную переменную для дальнейшего */

27  return 0; /* Вернуть 0 для продолжения */

28

29 case FTW_DCHP:

30  error(0, errno, _("cannot change to parent of directory %s"),

31  quote(file));

32  G_fail = 1;

33  return 0;

34

35 case FTW_DCH:

36  /* Нельзя просто вернуться, поскольку, хотя nftw не может войти в

37     каталог, она может использовать stat, постольку у нас есть размер */

38  error(0, errno, _("cannot change to directory %s"), quote(file));

39  G_fail = 1;

40  break;

41

42 case FTW_DNR:

43  /* Нельзя просто вернуться, поскольку, хотя nftw не может прочесть

44     каталог, она может вызвать stat, постольку у нас есть размер. */

45  error(0, errno, _("cannot read directory %s"), quote(file));

46  G_fail = 1;

47  break;

48

49 default:

50  break;

51 }

52

53 /* Если это первая (предварительная) встреча с каталогом,

54    сразу вернуться. */

55 if (file_type == FTW_DPRE)

56  return 0;

Строки 22–51 являются стандартным оператором switch. Ошибки, для которых нет информации о размере, устанавливают глобальную переменную G_fail в 1 и возвращают 0, чтобы продолжить обработку (см строки 24–27 и 29–33). Ошибки, для которых есть размер, также устанавливают G_fail, но затем прерывают switch для того, чтобы обработать статистику (см. строки 35–40 и 42–47).

Строки 55–56 сразу завершают функцию, если это первая встреча с каталогом

58 /* Если файл исключается или если он уже учитывался

59    через прямую ссылку, не включать его в сумму. */

60 if (info->skip,

61  || (!opt_count_all

62  && 1 < sb->st_nlink

63  && hash_ins(sb->st_ino, sb->st_dev)))

64 {

65  /* Заметьте, мы не должны здесь просто возвращаться.

66     Нам все еще нужно обновить prev_level и, возможно, передать

67     некоторые суммы выше по иерархии. */

68  size = 0;

69  print = 0;

70 }

71 else

72 {

73  size = (apparent_size

74    ? sb->st_size

75    : ST_NBLOCKS (*sb) * ST_NBLOCKSIZE);

76  }

Теперь становится интересно. По умолчанию du подсчитывает пространство, занимаемое прямыми ссылками, лишь одни раз. Опция --count-links заставляет ее подсчитывать пространство для каждой ссылки; переменная opt_count_all равна true, когда указана --count-links. Для отслеживания ссылок du содержит хэш-таблицу[87] уже встречавшихся пар (устройство, индекс).

Строки 60–63 проверяют, следует ли не включать файл в подсчет, либо из-за того, что он был исключен (info->skip равно true, строка 60), либо потому что не была указана --count-links (строка 61) и у файла несколько ссылок (строка 62) и файл уже находится в хеш-таблице (строка 63). В этом случае размер устанавливается в 0, поэтому он не входит в конечную сумму, a print также устанавливается в false (строки 68–69).

Если ни одно из этих условий не отмечается, размер вычисляется либо в соответствии с размером в struct stat, либо в соответствии с числом блоков диска (строки 73–75) Это решение основывается на переменной apparent_size, которая установлена при использовании опции --apparent-size.

78 if (first_call)

79 {

80  n_alloc = info->level + 10; /* Allocate arrays */

81  sum_ent = XCALLOC(uintmax_t, n_alloc); /* to hold sums */

82  sum_subdir = XCALLOC(uintmax_t, n_alloc);

83 }

84 else

85 {

86  /* FIXME: Стыдно, что нам нужно приводить к типу size_t для избежания

87     предупреждений gcc о 'сравнении между знаковым и беззнаковым'.

88     Возможно, неизбежно, при условии, что члены структуры FTW

89     имеют тип 'int' (исторически), так как мне нужно, чтобы переменные

90     вроде n_alloc и prev_level имели осмысленные типы. */

91  if (n_alloc <= (size_t)info->level)

92  {

93   n_alloc = info->level * 2; /* Удвоить сумму */

94   sum_ent = XREALLOC(sum_ent, uintmax_t, realloc); /* И выделить повторно */

95   sum_subdir = XREALLOC(sum_subdir, uintmax_t, n_alloc);

96  }

97 }

98

99 size_to_print = size;

Строки 78–97 управляют динамической памятью, используемой для хранения статистики о размере файла, first_call является статической переменной (строка 12), которая равна true при первом вызове process_file(). В этом случае вызывается calloc() (через упаковывающий макрос в строках 81–82; это обсуждалось в разделе 3.2.1.8 «Пример чтение строк произвольной длины»). Остальную часть времени first_call равно false, и используется realloc() (снова через упаковывающий макрос, строки 91–96).

Строка 99 заносит значение size в size_to_print; эта переменная может обновляться в зависимости от того, должна ли она включать размеры дочерних элементов. Хотя size могла бы использоваться повторно, отдельная переменная упрощает чтение кода.

101 if (!first_call)

102 {

103  if ((size_t)info->level == prev_level)

104  {

105   /* Обычно самый частый случай. Ничего не делать. */

106  }

107  else if ((size_t)info->level > prev_level)

108  {

109   /* Нисхождение по иерархии.

110      Очистить аккумуляторы для *всех* уровней между prev_level

111      и текущим. Глубина может значительно меняться,

112      например, от 1 до 10. */

113   int i;

114   for (i = prev_level +1; i <= info->level; i++)

115    sum_ent[i] = sum_subdir[i] = 0;

116  }

117  else /* info->level < prev_level */

118  {

119   /* Восхождение по иерархии.

120      nftw обрабатывает каталог лишь после всех элементов,

121      в которых был обработан каталог. Когда глубина уменьшается,

122      передать суммы от детей (prev_level) родителям.

123      Здесь текущий уровень всегда меньше, чем

124      предыдущий. */

125   assert (<size_t) info->level == prev_level - 1);

126   size_to_print += sum_ent[prev_level];

127   if (!opt_separate_dirs)

128    size_to_print += sum_subdir[prev_level];

129   sum_subdir[info->level] += (sum_ent[prev_level]

130    + sum_subdir[prev_level]);

131  }

132 }

Строки 101–132 сравнивают текущий уровень с предыдущим. Возможны три случая.

Уровни те же самые

В этом случае нет необходимости беспокоиться о статистике дочерних элементов. (Строки 103–106.)

Текущий уровень выше предыдущего

В этом случае мы спустились по иерархии, и статистику нужно восстановить (строки 107–116). Термин «аккумулятор» в комментарии подходящий: каждый элемент аккумулирует общее дисковое пространство, использованное на этом уровне. (На заре вычислительной техники регистры центрального процессора часто назывались «аккумуляторами».)

Текущий уровень ниже предыдущего

В этом случае мы завершили обработку всех дочерних элементов каталога и только что вернулись обратно в родительский каталог (строки 117–131). Код обновляет суммы, включая size_to_print.

134 prev_level = info->level; /* Установить статические переменные */

135 first_call = 0;

136

137 /* Включить элемент каталога в общую сумму для содержащего

138    каталога, если не указана --separate-dirs (-S). */

139 if (!(opt_separate_dirs && IS_FTW_DIR_TYPE(file_type)))

140  sum_ent[info->level] += size;

141

142 /* Даже если каталог нельзя прочесть или перейти в него,

143    включить его размер в общую сумму, ... */

144 tot_size += size;

145

146 /* ...но не выводить для него итог, поскольку без размера(-ов)

147    потенциальных элементов, это может сильно запутывать. */

148 if (file_type == FTW_DNR || file_type == FTW_DCH)

149  return 0;

150

151 /* Если мы не считаем элемент, например, потому что это прямая

152    ссылка на файл, который уже посчитан (и --count-links), не

153    выводить для него строку. */

154 if (!print)

155  return 0;

Строки 134–135 устанавливают статические переменные prev_level и first_call таким образом, что они содержат правильные значения для последующего вызова process_file(), гарантируя, что весь предыдущий код работает правильно.

Строки 137–144 выверяют статистику на основе опций и типа файла. Комментарии и код достаточно просты. Строки 146–155 сразу завершают функцию, если сведения не должны выводиться.

157  /* FIXME: Это выглядит подозрительно годным для упрощения. */

158  if ((IS_FTW_DIR_TYPE(file_type) &&

159   (info->level <= max_depth || info->level == 0))

160   || <(opt_all && info->level <= max_depth) || info->level == 0))

161  {

162   print_only_size(size_to_print);

163   fputc('\t', stdout);

164   if (arg_length)

165   {

166    /* Вывести имя файла, но без суффикса каталога '.' или '/.'

167       который мы, возможно, добавили в main. */

168    /* Вывести все до добавленной нами части. */

169    fwrite(file, arg_length, 1, stdout);

170    /* Вывести все после добавленного нами. */

171    fputs(file + arg_length + suffix_length

172     + (file[arg_length + suffix_length] == '/'), stdout);

173   }

174   else

175   {

176    fputs(file, stdout);

177   }

178   fputc('\n', stdout);

179   fflush(stdout);

180  }

181

182  return 0;

183 }

Условие в строках 158–160 сбивает с толку, и комментарий в строке 157 указывает на это. Условие утверждает: «Если (1a) файл является каталогом и (1b) уровень меньше максимального для вывода (переменные — -max-depth и max_depth) или нулевой, или (2a) должны быть выведены все файлы и уровень меньше, чем максимальный для вывода, или (2b) уровень нулевой», тогда вывести файл. (Версия du после 5.0 использует в этом случае несколько менее запутанное условие.)

Строки 162–179 осуществляют вывод. Строки 162–163 выводят размер и символ TAB Строки 164–173 обрабатывают специальный случай. Это объяснено далее в du.c, в строках файла 524–529:

524 /* При разыменовании лишь аргументов командной строки мы

525    используем флаг nftw FTW_PHYS, поэтому символическая ссылка

526    на каталог, указанная в командной строке, в норме не

527    разыменовывается. Для решения этого мы идем на издержки,

528    сначала добавляя '/.' (или '.'), а затем удаляем их каждый раз

529    при выводе имени производного файла или каталога. */

В этом случае arg_length равен true, поэтому строки 164–173 должны вывести первоначальное имя, а не измененное В противном случае строки 174–177 могут вывести имя как есть.

Фу! Куча кода. Мы находим, что это верхний уровень спектра сложности, по крайней мере, насколько это может быть просто представлено в книге данного содержания. Однако, он демонстрирует, что код из реальной жизни часто бывает сложным. Лучшим способом справиться с этой сложностью является ясное именование переменных и подробные комментарии du.с в этом отношении хорош; мы довольно легко смогли извлечь и изучить код без необходимости показывать все 735 строк программы!

8.6. Изменение корневого каталога: chroot()

Текущий рабочий каталог, установленный с помощью chdir() (см. раздел 8.4.1 «Изменение каталога — chdir() и fchdir()»), является атрибутом процесса, таким же, как набор открытых файлов. Он также наследуется новыми процессами.

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

#include <unistd.h> /* Обычный */


int chroot(const char *path);

Возвращаемое значение равно 0 при успешном завершении и -1 при ошибке.

Как указывает справочная страница GNU/Linux chroot(2), изменение корневого каталога не изменяет текущий каталог: программы, которые должны обеспечить нахождение под новым корневым каталогом, должны также вызвать затем chdir():

if (chroot("/new/root") < 0) /* Установить новый корневой каталог */

 /* обработать ошибку */

if (chdir("/some/dir") < 0) /* Пути даны не относительно нового корневого каталога */

 /* обработать ошибку */

Системный вызов chroot() чаще всего используется для демонов — фоновых программ, которые должны работать в специальном ограниченном окружении. Например, рассмотрите демон Интернета FTP, допускающий анонимный FTP (соединение любого клиента из любого места, без обычных имени пользователя и пароля). Очевидно, такое соединение не должно быть способным видеть все файлы целой системы. Вместо этого демон FTP выполняет chroot() в специальный каталог со структурой, достаточной лишь чтобы позволить ему функционировать. (Например, со своим собственным /bin/ls для перечисления файлов, со своей копией библиотеки С времени исполнения, если она разделяется, и, возможно, со своей копией /etc/passwd и /etc/group для отображения ограниченного набора имен пользователей и групп.)

POSIX не стандартизует этот системный вызов, хотя GNU/Linux и все системы Unix его поддерживают. (Он популярен с V7.) Он специализирован, но при необходимости очень удобен.

8.7. Резюме

• Файловые системы являются коллекциями блоков индексов, данных, вспомогательных данных и свободных блоков, организованных особым способом. Файловые системы один к одному соответствуют (физическим или логическим) разделам, на которых они создаются. У каждой файловой системы есть свой корневой каталог; по соглашению, у корневого каталога номер индекса всегда равен 2.

• Команда mount монтирует файловую систему, наращивая логическое иерархическое пространство имен файлов. Команда umount отсоединяет файловую систему. Ядро делает /. и /.. одним и тем же; корневой каталог всего пространства имен является своим собственным родителем. Во всех остальных случаях ядро устанавливает в корневом каталоге смонтированной файловой системы указывающим на родительский каталог точки монтирования.

• Современные Unix-системы поддерживают множество типов файловых систем. В частности, повсеместно поддерживается сетевая файловая система (NFS) Sun, также, как ISO 9660 является стандартным форматом для CD-ROM, а разделы FAT MS- DOS поддерживаются на всех Unix-системах, работающих на платформе Intel x86. Насколько мы знаем, Linux поддерживает наибольшее число различных файловых систем — свыше 30! Многие из них специализированные, но многие из оставшихся предназначены для общего использования, включая по крайней мере четыре различные журналируемые файловые системы.

• Файл /etc/fstab перечисляет разделы каждой системы, их точки монтирования и относящиеся к монтированию опции, /etc/mtab перечисляет те файловые системы, которые смонтированы в настоящее время, то же делает /proc/mounts на системах GNU/Linux. Опция loop функции mount особенно полезна под GNU/Linux для монтирования образов файловых систем, содержащихся в обычных файлах, таких, как образы CD-ROM. Другие опции полезны для безопасности и монтирования внешних файловых систем, таких, как файловые системы vfat Windows.

• Файлы формата /etc/fstab можно читать с помощью набора процедур getmntent(). Формат GNU/Linux общий с рядом других коммерческих вариантов Unix, особенно Sun Solaris.

• Функции statvfs() и fstatvfs() стандартизованы POSIX для получения сведений о файловой системе, таких, как число свободных и используемых дисковых блоков, число свободных и используемых индексов и т.д. В Linux есть свой собственный системный вызов для получения подобной информации: statfs() и fstatfs().

• chdir() и fchdir() дают процессу возможность изменить его текущий каталог, getcwd() получает абсолютное имя пути текущего каталога. Эти три функции просты в использовании.

• Функция nftw() централизует задачу «обхода дерева файлов», т.е. посещения каждого объекта файловой системы (файла, устройства, символической ссылки, каталога) во всей иерархиикаталогов. Ее поведением управляют различные флаги. Программист должен предоставить функцию обратного вызова, которая получает имя каждого файла, struct stat для файла, тип файла и сведения об имени файла и уровне в иерархии. Эта функция может делать для каждого файла все что нужно. Версия функции du из Coreutils 5.0 GNU использует для выполнения этой работы расширенную версию nftw().

• Наконец, системный вызов chroot() изменяет текущий корневой каталог процесса. Это специализированная, но важная возможность, которая особенно полезна для определенных программ в стиле демонов.

Упражнения

1. Изучите справочную страницу mount(2) под GNU/Linux и на всех различных системах Unix, к которым у вас есть доступ. Как отличаются системные вызовы?

2. Усовершенствуйте программу ch08-statvfs.c, чтобы она принимала опцию, предоставляющую открытый целый дескриптор файла; для получения сведений о файловой системе она должна использовать fstatvfs().

3. Усовершенствуйте ch08-statvfs.c, чтобы она не игнорировала смонтированные файловые системы NFS. Такие файловые системы имеют устройство в форме server.example.com:/big/disk.

4. Измените ch08-statfs.c (ту, которая использует специфичный для Linux вызов statfs()), чтобы ее вывод был похож на вывод df.

5. Добавьте опцию -i к программе, которую вы написали для предыдущего упражнения, чтобы ее вывод был такой же, как у 'df -i'.

6. Используя opendir(), readdir(), stat() или fstat(), dirfd() и fchdir(), напишите собственную версию getcwd(). Как вы вычислите общий размер, который должен иметь буфер? Как вы будете перемещаться по иерархии каталогов?

7. Усовершенствуйте свою версию getcwd(), чтобы она выделяла буфер для вызывающего, если первый аргумент равен NULL.

8. Можете ли вы использовать nftw() для написания getcwd()? Если нет, почему?

9. Используя nftw(), напишите свою собственную версию chown, которая принимает опцию -R для рекурсивной обработки целых деревьев каталогов. Убедитесь, что без -R, 'chown пользователь каталог' не является рекурсивной. Как вы это проверите?

10. Набор процедур BSD fts() («file tree stream» — «поток дерева файлов») предоставляет другой способ для обработки иерархии каталогов. У него несколько более тяжелый API как в смысле числа функций, так и структур, которые доступны для вызывающих функций уровня пользователя. Эти функции доступны как стандартная часть GLIBC.

Прочтите справочную страницу fts(3). (Для удобства ее можно распечатать.) Перепишите свою частную версию chown для использования fts().

11. Посмотрите справочную страницу find(1). Если бы вы пытались написать find с самого начала, какой набор деревьев файлов вы бы предпочли, nftw() или fts()? Почему?

Часть 2 Процессы, IPC и интернационализация

Глава 9 Управление процессами и каналы

Как мы говорили в главе 1 «Введение», если бы нужно было резюмировать Unix (а следовательно, и Linux) в трёх словах, это были бы «файлы и процессы». Теперь, когда мы увидели, как работать с файлами и каталогами, время взглянуть на оставшуюся часть утверждения: процессы. В частности, мы исследуем, как создаются и управляются процессы, как они взаимодействуют с открытыми файлами и как они могут взаимодействовать друге другом. Последующие главы исследуют сигналы — грубый способ дать возможность одному процессу (или ядру) сообщить другому о том, что произошло некоторое событие — и проверку прав доступа.

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

9.1. Создание и управление процессами

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

9.1.1. Создание процесса: fork()

Первым шагом в запуске новой программы является вызов fork():

#include <sys/types.h> /* POSIX */

#include <unistd.h>


pid_t fork(void);

Использование fork() просто. Перед вызовом один процесс, который мы называем родительским, является запущенным. Когда fork() возвращается, имеется уже два процесса: родительский и порожденный (child).

Вот ключ: оба процесса выполняют одну и ту же программу. Два процесса могут различить себя, основываясь на возвращённом fork() значении:

Отрицательное

Если была ошибка, fork() возвращает -1, а новый процесс не создается. Работу продолжает первоначальный процесс.

Нулевое

В порожденном процессе fork() возвращает 0.

Положительное

В родительском процессе fork() возвращает положительный идентификационный номер (PID) порожденного процесса.

Код шаблона для создания порожденного процесса выглядит следующим образом:

pid_t child;

if ((child = fork()) < 0)

 /* обработать ошибку */

else if (child == 0)

 /* это новый процесс */

else

 /* это первоначальный родительский процесс */

pid_t является знаковым целым типом для хранения значений PID. Скорее всего, это просто int, но специальный тип делает код более понятным, поэтому он должен использоваться вместо int.

На языке Unix, помимо названия системного вызова, слово «fork» является и глаголом, и существительным[88]. Мы можем сказать, что «один процесс ответвляет другой», и что «после разветвления работают два процесса». (Думайте «развилка (fork) на дороге», а не «вилка (fork), нож и ложка».)

9.1.1.1. После fork(): общие и различные атрибуты

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

• Окружение, см. раздел 2.4 «Окружение».

• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 5.3.1 «Базовое чтение каталогов».

• Установки umask; см. раздел 4.6 «Создание файлов».

• Текущий рабочий каталог; см раздел 8.4.1 «Смена каталога: chdir() и fchdir().

• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога: chroot()».

• Текущий приоритет (иначе называемый «значение nice»; вскоре мы это обсудим; см раздел 9.1.3 «Установка приоритета процесса: nice()»).

• Управляющие терминалы. Это устройство терминала (физическая консоль или окно эмулятора терминала), которому разрешено посылать процессу сигналы (такие, как CTRL-Z для прекращения выполняющихся работ). Это обсуждается далее в разделе 9.2.1 «Обзор управления работой».

• Маска сигналов процесса и расположение всех текущих сигналов (еще не обсуждалось; см. главу 10 «Сигналы»).

• Реальный, эффективный и сохраненный ID пользователя, группы и набора дополнительных групп (еще не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы»).

Помимо возвращаемого значения fork() два процесса различаются следующим образом:

• У каждого есть уникальный ID процесса и ID родительского процесса (PID и PPID) Они описаны в разделе 9.1.2 «Идентификация процесса: getpid() и getppid()».

• PID порожденного процесса не будет равняться ID любой существующей группы процессов (см. раздел 9.2 «Группы процессов»).

• Аккумулированное время использования процессора для порожденного процесса и его будущих потомков инициализируется нулем. (Это имеет смысл; в конце концов, это совершенно новый процесс.)

• Любые сигналы, которые были ожидающими в родительском процессе, в порожденном сбрасываются, также как ожидающие аварийные сигналы и таймеры. (Мы еще не рассматривали эти темы; см. главу 10 «Сигналы» и раздел 14.3.3 «Интервальные таймеры: setitimer() и getitimer()».)

• Блокировки файлов в родительском процессе не дублируются в порожденном (также еще не обсуждалось; см. раздел 14.2 «Блокировка файлов»).

9.1.1.2. Разделение дескрипторов файлов

Атрибуты, которые порожденный процесс наследует от родителя, устанавливаются в те же значения, которые были в родительском процессе в момент выполнения fork(). Однако, с этого момента два процесса продолжают идти собственными путями (большей частью) независимо один от другого. Например, если порожденный процесс изменяет каталог, каталог родительского процесса не затрагивается. Сходным образом, если порожденный изменяет среду, среда родителя не меняется.

Открытые файлы являются важным исключением из этого правила. Дескрипторы открытых файлов являются разделяемыми, и действия одного процесса с разделяемым дескриптором файла затрагивает состояние файла также и для другого процесса. Это лучше всего понять, изучив рис. 9.1.

Рис. 9.1. Разделение дескрипторов файлов

Рисунок отображает внутренние структуры данных ядра. Ключевой структурой данных является таблица файлов. Каждый элемент ссылается на открытый файл. Помимо других учетных данных, таблица файлов содержит текущее положение (смещение чтения/записи) в файле. Оно устанавливается либо автоматически каждый раз при чтении или записи файла, либо непосредственно через lseek() (см. раздел 4.5 «Произвольный доступ: перемещения внутри файла»).

Дескриптор файла, возвращенный функциями open() или creat(), действует как индекс имеющегося в каждом процессе массива указателей на таблицу файлов. Размер этого массива не превышает значение, возвращенное getdtablesize() (см. раздел 4.4.1 «Понятие о дескрипторах файлов»).

На рис. 9.1 показаны два процесса, разделяющие стандартный ввод и стандартный вывод; для каждого из процессов указаны одни и те же элементы в таблице файлов. Поэтому, когда процесс 45 (порожденный) осуществляет read(), общее смещение обновляется; следующий раз, когда процесс 42 (родитель) осуществляет read(), он начинает с позиции, в которой закончила чтение read() процесса 45.

Это легко можно видеть на уровне оболочки:

$ cat data /* Показать содержание демонстрационного файла */

line 1

line 2

line 3

line 4

$ ls -l test1 ; cat test1 /* Режим и содержание тестовой программы */

-rwxr-xr-x 1 arnold devel 93 Oct 20 22:11 test1

#! /bin/sh

read line ; echo p: $line /* Прочесть строку в родительской оболочке,

                             вывести ее */

( read line ; echo с: $line ) /* Прочесть строку в порожденной оболочке,

                                 вывести ее */

read line ; echo p: $line /* Прочесть строку в родительской оболочке,

                             вывести ее */

$ test1 < data /* Запустить программу */

p: line 1 /* Родитель начинает сначала */

c: line 2 /* Порожденный продолжает оттуда, где остановился родитель */

p: line 3 /* Родитель продолжает оттуда, где остановился порожденный */

Первая исполняемая строка test1 читает из стандартного ввода строку, изменяя смещение файла. Следующая строка test1 запускает команды, заключенные между скобками, в подоболочке (subshell). Это отдельный процесс оболочки, созданный — как вы догадались — с помощью fork(). Порожденная подоболочка наследует от родителя стандартный ввод, включая текущее смещение. Этот процесс читает строку и обновляет разделяемое смещение в файле. Когда третья строка, снова в родительской оболочке, читает файл, она начинает там, где остановился порожденный.

Хотя команда read встроена в оболочку, все работает таким же образом и для внешних команд. В некоторых ранних Unix-системах была команда line, которая читала одну строку ввода (по одному символу за раз!) для использования в сценариях оболочки; если бы смещение файла не было разделяемым, было бы невозможно использовать такую команду в цикле.

Разделение дескрипторов файлов и наследование играют центральную роль в перенаправлении ввода/вывода оболочки; системные вызовы и их семантика делают примитивы уровня оболочки простыми для реализации на С, как мы позже увидим в данной главе.

9.1.1.3. Разделение дескрипторов файлов и close()

Тот факт, что несколько дескрипторов файлов могут указывать на один и тот же открытый файл, имеет важное следствие: файл не закрывается до тех пор, пока не будут закрыты все дескрипторы файла.

Позже в главе мы увидим, что несколько дескрипторов для одного файла могут существовать не только для разных процессов, но даже и внутри одного и того же процесса; это правило особенно важно для работы с каналами (pipes).

Если вам нужно узнать, открыты ли два дескриптора для одного и того же файла, можете использовать fstat() (см. раздел 5.4.2 «Получение сведений о файле») для двух дескрипторов с двумя различными структурами struct stat. Если соответствующие поля st_dev и st_ino равны, это один и тот же файл.

Позже в главе мы завершим обсуждение манипуляций с дескрипторами файлов и таблицей дескрипторов файлов.

9.1.2. Идентификация процесса: getpid() и getppid()

У каждого процесса есть уникальный ID номер процесса (PID). Два системных вызова предоставляют текущий PID и PID родительского процесса:

#include <sys/types.h> /* POSIX */

#include <unistd.h>


pid_t getpid(void);

pid_t getppid(void);

Функции так просты, как выглядят:

pid_t getpid(void) Возвращает PID текущего процесса

pid_t getppid(void)Возвращает PID родителя.

Значения PID уникальны; по определению, не может быть двух запущенных процессов с одним и тем же PID. PID обычно возрастают в значении, так что порожденный процесс имеет обычно больший PID, чем его родитель. Однако, на многих системах значения PID переполняются; когда достигается значение системного максимума для PID, следующий процесс создается с наименьшим не используемым номером PID. (Ничто в POSIX не требует такого поведения, и некоторые системы назначают неиспользуемые номера PID случайным образом.)

Если родительский процесс завершается, порожденный получает нового родителя, init. В этом случае PID родителя будет 1, что является PID init. Такой порожденный процесс называется висячим (orphan). Следующая программа, ch09-reparent.с, демонстрирует это. Это также первый пример fork() в действии:

1  /* ch09-reparent.c --- показывает, что getppid() может менять значения */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <sys/types.h>

6  #include <unistd.h>

7

8  /* main --- осуществляет работу */

9

10 int main(int argc, char **argv)

11 {

12  pid_t pid, old_ppid, new_ppid;

13  pid_t child, parent;

14

15  parent = getpid(); /* перед fork() */

16

17  if ((child = fork()) < 0) {

18   fprintf(stderr, "%s: fork of child failed: %s\n",

19    argv[0], strerror(errno));

20   exit(1);

21  } else if (child == 0) {

22   old_ppid = getppid();

23   sleep(2); /* см. главу 10 */

24   new_ppid = getppid();

25  } else {

26   sleep(1);

27   exit(0); /* родитель завершается после fork() */

28  }

29

30  /* это выполняет только порожденный процесс */

31  printf("Original parent: %d\n", parent);

32  printf("Child: %d\n", getpid());

33  printf("Child's old ppid: %d\n", old_ppid);

34  printf("Child's new ppid: %d\n", new_ppid);

35

36  exit(0);

37 }

Строка 15 получает PID начального процесса, используя getpid(). Строки 17–20 создают порожденный процесс, проверяя по возвращении ошибки.

Строки 21–24 выполняются порожденным процессом: строка 22 получает PPID. Строка 23 приостанавливает процесс на две секунды (сведения о sleep() см в разделе 10.8.1 «Аварийные часы: sleep(), alarm() и SIGALRM»), а строка 24 снова получает PPID.

Строки 25–27 исполняются в родительском процессе. Строка 26 задерживает родителя на одну секунду, давая порожденному процессу достаточно времени для осуществления первого вызова getppid(). Строка 27 завершает родителя.

Строки 31–34 выводят значения. Обратите внимание, что переменная parent, которая была установлена до разветвления, сохраняет свое значение в порожденном процессе. После порождения у двух процессов идентичные, но независимые копии адресного пространства. Вот что происходит при запуске программы:

$ ch09-reparent /* Запуск программы */

$ Original parent: 6582 /* Программа завершается: приглашение оболочки

                           и вывод порожденного процесса */

Child: 6583

Child's old ppid: 6582

Child's new ppid: 1

Помните, что обе программы выполняются параллельно. Графически это изображено на рис. 9.2.

Рис. 9.2. Два параллельно исполняющихся процесса после разветвления

ЗАМЕЧАНИЕ. Использование sleep(), чтобы заставить один процесс пережить другой, работает в большинстве случаев. Однако, иногда случаются ошибки, которые трудно воспроизвести и трудно обнаружить. Единственным способом гарантировать правильное поведение является явная синхронизация с помощью wait() или waitpid(), которые описываются далее в главе (см. раздел 9.1.6.1 «Использование функций POSIX: wait() и waitpid()»).

9.1.3. Установка приоритетов процесса: nice()

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

Linux, как и Unix, обеспечивает вытесняющую многозадачность. Это означает, что ядро может вытеснить процесс (приостановить его), если настало время дать возможность поработать другому процессу. Приоритет длительное время работающих процессов (например, процессов, выполняющих интенсивные вычисления), снижается в конце их кванта времени, поэтому они дают шанс другим процессам получить время процессора. Сходным образом, процессам, длительное время бездействовавшим в ожидании завершения ввода/вывода (таким, как интерактивный текстовый редактор), приоритет повышается, так что они могут ответить на ввод/вывод, когда он происходит. Короче, ядро гарантирует, что все процессы, усредненные по времени, получают свою «справедливую долю» времени процессора. Повышение и понижение приоритетов является частью этого процесса.

Проектирование хорошего планировщика процессов для ядра является искусством; практические подробности выходят за рамки данной книги. Однако, процесс может влиять на назначения приоритетов ядром посредством своего значения относительного приоритета (nice).

Значение относительного приоритета является указанием того, насколько «приятным» хочет быть процесс в отношении других процессов. В соответствии с этим большие значения означают во все большей степени терпеливые процессы; т.е. те, которые все более приятны другим, снижая свой приоритет по отношению к ним.

Отрицательное значение относительного приоритета, с другой стороны, означает, что процесс желает быть «менее приятным» по отношению к другим. Такой процесс более эгоистичный, требуя себе большего количества времени процессора[89]. К счастью, в то время как пользователи могут повышать значение относительного приоритета (быть более приятными), лишь root может снижать значение относительного приоритета (быть менее приятным).

Значение относительного приоритета является лишь одним фактором в уравнении, используемом ядром для вычисления приоритета; это не значение самого приоритета, которое изменяется с течением времени на основе поведения процесса и состояния других процессов системы. Для изменения значения относительного приоритета используется системный вызов nice():

#include <unistd.h> /* XSI */


int nice(int inc);

Значение относительного приоритета по умолчанию равно 0. Разрешен диапазон значений от -20 до 19. Это требует некоторой привычки. Чем более отрицательное значение, тем выше приоритет процесса: -20 является наивысшим приоритетом (наименьшая приятность), а 19 — наинизшим приоритетом (наибольшая приятность)

Аргумент inc является приращением, на который надо изменить значение приоритета. Для получения текущего значения, не изменяя его, используйте 'nice(0)'. Если результат 'текущий_относительный_приоритет + inc' выйдет за пределы от -20 до 19, система принудительно включит его в этот диапазон.

Возвращаемое значение является новым значением относительного приоритета или -1, если возникла ошибка. Поскольку -1 также является действительным значением относительного приоритета, при вызове nice() следует сначала явным образом установить errno в ноль, а затем проверить его насчет имевшихся проблем:

int niceval;

int inc = /* любое значение */;

errno = 0;

if ((niceval = nice(inc)) < 0 && errno != 0) {

 fprintf(stderr, "nice(%d) failed: %s\n", inc, strerror(errno));

 /* другое восстановление */

}

Этот пример может завершиться неудачей, если в inc отрицательное значение, а процесс не запущен как root.

9.1.3.1. POSIX против действительности

Диапазон значений относительного приоритета от -20 до 19, которые использует Linux, имеет исторические корни; он ведет начало по крайней мерее V7. POSIX выражает состояние менее прямым языком, что дает возможность большей гибкости, сохраняя в то же время историческую совместимость. Это также затрудняет чтение и понимание стандарта, вот почему вы и читаете эту книгу. Итак, вот как описывает это POSIX

Во-первых, значение относительного приоритета процесса, поддерживаемое системой, колеблется от 0 до '(2 * NZERO) - 1'. Константа NZERO определена в <limits.h> и должна равняться по крайней мере 20. Это дает диапазон 0–39.

Во-вторых, как мы описывали, сумма текущего значения относительного приоритета и приращение incr загоняются в этот диапазон.

В заключение, возвращаемое nice() значение является значением относительного приоритета процесса минус NZERO. При значении NZERO 20 это дает первоначальный диапазон от -20 до 19, который мы описали вначале.

Результатом является то, что возвращаемое nice() значение в действительности изменяется от '-NZERO' до 'NZERO-1', и лучше всего писать свой код в терминах этой именованной константы. Однако, на практике трудно найти систему, в которой NZERO не было бы равно 20.

9.1.4. Запуск новой программы: семейство exec()

После запуска нового процесса (посредством fork()) следующим шагом является запуск в процессе другой программы. Имеется несколько функций, которые служат различным целям:

#include <unistd.h> /* POSIX */


int execve(const char *filename, /* Системный вызов */

char *const argv[], char *const envp[]);

int execl(const char *path, const char *arg, ...); /* Оболочки */

int execlp(const char *file, const char *arg, ...);

int execle(const char *path, const char *arg, ..., char *const envp[]);

int execv(const char *path, char *const argv[]);

int execvp(const char *file, char *const argv[]);

Мы ссылаемся на эти функции как на «семейство exec()». Функции с именем exec() нет; вместо этого мы используем это имя для обозначения любой из перечисленных выше функций. Как и в случае с fork(), «exec» используется на языке Unix и в качестве глагола, означающего исполнение (запуск) программы, и в качестве существительного.

9.1.4.1. Системный вызов execve()

Простейшей для объяснения функцией является execve(). Она является также лежащим в основе системным вызовом. Другие являются функциями-оболочками, как вскоре будет объяснено.

int execve(const char *filename, char *const argv[],

 char* const envp[]);

filename является именем программы для исполнения. Это может быть именем полного или относительного пути. Файл должен иметь формат исполняемого файла, который понимает ядро. Современные системы используют формат исполняемого файла ELF (Extensible Linking Format — открытый формат компоновки). GNU/Linux распознает ELF и несколько других форматов. С помощью execve() можно исполнять интерпретируемые сценарии, если они используют особую первую строку с именем интерпретатора, начинающуюся с '#!'. (Сценарии, которые не начинаются с '#!', потерпят неудачу.) В разделе 1.1.3 «Исполняемые файлы» представлен пример использования '#!'. argv является стандартным списком аргументов С — массив символьных указателей на строки аргументов, включая значение для использования с argv[0][90], завершающийся указателем NULL.

envp является окружением для использования новым процессом, с таким же форматом, как глобальная переменная environ (см. раздел 2.4 «Переменные окружения»). В новой программе это окружение становится начальным значением environ.

Программа не должна возвращаться из вызова exec(). Если она возвращается, возникла проблема. Чаще всего либо не существует затребованная программа, либо она существует, но не является исполняемой (значения для errno ENOENT и EACCESS соответственно). Может быть множество других ошибок; см. справочную страницу execve(2).

В предположении, что вызов был успешным, текущее содержимое адресного пространства процесса сбрасывается. (Ядро сначала сохраняет в безопасном месте данные argv и envp.) Ядро загружает для новой программы исполняемый код вместе со всеми глобальными и статическими переменными. Затем ядро инициализирует переменные окружения переданными execve() данными, а далее вызывает процедуру main() новой программы с переданным функции execve() массивом argv. Подсчитывается число аргументов и это значение передается main() в argc.

К этому моменту новая программа запущена. Она не знает (и не может определить), какая программа была в процессе до нее. Обратите внимание, что ID процесса не меняется. Многие другие атрибуты при вызове exec сохраняются; вскоре мы рассмотрим это более подробно.

exec() для процесса можно сравнить с ролями, которые играют в жизни люди. В различное время в течение дня один человек может быть родителем, супругом, другом, студентом или рабочим, покупателем в магазине и т.д. Это одна и та же личность, исполняющая различные роли. Также и процесс — его PID, открытые файлы, текущий каталог и т.п. — не изменяются, тогда как выполняемая работа - запущенная с помощью exec() программа — может измениться.

9.1.4.2. Функции-оболочки: execl() и др.

Пять дополнительных функций, действующих в качестве оболочек, предоставляют более удобные интерфейсы для execve(). В первой группе все принимают список аргументов, каждый из которых передается в виде явного параметра функции:

int execl(const char *path, const char *arg, ...)

Первый аргумент, path, является путем к исполняемому файлу. Последующие аргументы, начиная с arg, являются отдельными элементами, которые должны быть помещены в argv. Как и ранее, явным образом должен быть включен argv[0]. Вы должны в качестве последнего аргумента передать завершающий указатель NULL, чтобы execl() смогла определить, где заканчивается список аргументов. Новая программа наследует любые переменные окружения, которые находятся в переменной environ.

int execlp(const char *file, const char *arg, ...)

Эта функция подобна execl(), но она имитирует механизм поиска команд оболочки, разыскивая file в каждом каталоге, указанном в переменной окружения PATH. Если file содержит символ /, этот поиск не осуществляется. Если PATH в окружении не присутствует, execlp() использует путь по умолчанию. В GNU/Linux по умолчанию используется ":/bin:/usr/bin", но в других системах может быть другое значение. (Обратите внимание, что ведущее двоеточие в PATH означает, что сначала поиск осуществляется в текущем каталоге.)

Более того, если файл найден и имеет право доступа на исполнение, но не может быть исполнен из-за того, что неизвестен его формат, execlp() считает, что это сценарий оболочки и запускает оболочку с именем файла в качестве аргумента.

int execle(const char *path, const char *arg, ...,

 char *const envp[])

Эта функция также подобна execl(), но принимает дополнительный аргумент, envp, который становится окружением новой программы. Как и в случае с execl(), вы должны для завершения списка аргументов поместить перед envp указатель NULL.

Вторая группа функций-оболочек принимает массив в стиле argv:

int execv(const char *path, char *const argv[])

Эта функция подобна execve(), но новая программа наследует любое окружение, которое находится в переменной environ текущей программы.

int execvp(const char *file, char *const argv[])

Эта функция подобна execv(), но она осуществляет такой же поиск в PATH, как и функция execlp(). Она также переходит на исполнение сценария оболочки, если найденный файл не может быть исполнен непосредственно.

В табл. 9.1 подведены итоги для шести функций exec().


Таблица 9.1. Сводка семейства функций exec() по алфавиту

Функция Поиск пути Окружение пользователя Назначение
execl() Исполняет список аргументов.
execle() Исполняет список аргументов с окружением.
execlp() Исполняет список аргументов с поиском пути
execv() Исполняет с argv
execve() Исполняет с argv и окружением (системный вызов).
execvp() Исполняет с argv и с поиском пути
Функций execlp() и execvp() лучше избегать, если вы не знаете, что переменная окружения PATH содержит приемлемый список каталогов.

9.1.4.3. Имена программ и argv[0]

До сих пор мы все время считали argv[0] именем программы. Мы знаем, что оно может содержать, а может и не содержать символ /, в зависимости от способа вызова программы, если этот символ содержится, это хорошая подсказка к тому, что для вызова программы использовалось имя пути.

Однако, как должно быть ясно к этому времени, то, что argv[0] содержит имя файла, является лишь соглашением. Ничто не может воспрепятствовать передаче вами вызываемой программе в качестве argv[0] произвольной строки. Следующая программа, ch09-run.c, демонстрирует передачу произвольной строки:

1  /* ch09-run.c --- запуск программы с другим именем и любыми аргументами */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <unistd.h>

6

7  /* main --- настроить argv и запустить указанную программу */

8

9  int main(int argc, char **argv)

10 {

11  char *path;

12

13  if (argc < 3) {

14   fprintf(stderr, "usage: %s path arg0 [ arg ... ]\n", argv[0]);

15   exit(1);

16  }

17

18  path = argv[1];

19

20  execv(path, argv + 2); /* skip argv[0] and argv[1] */

21

22  fprintf(stderr, "%s: execv() failed: %s\n", argv[0],

23   strerror(errno));

24  exit(1);

25 }

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

Строки 13–16 осуществляют проверку ошибок. Строка 18 сохраняет путь в path Строка 20 осуществляет exec; если программа доходит до строк 22–23, это указывает на ошибку. Вот что происходит при запуске программы:

$ ch09-run /bin/grep whoami foo /* Запустить grep */

a line /* Входная строка не подходит */

a line with foo in it /* Входная строка подходит */

a line with foo in it /* Это выводится */

^D /* EOF */

$ ch09-run nonexistent-program foo bar /* Демонстрация неудачи */

ch09-run: execv() failed: No such file or directory

Следующий пример несколько неестественен: мы заставили ch09-run запустить себя, передав в качестве имени программы 'foo'. Поскольку аргументов для второго запуска недостаточно, она выводит сообщение об использовании и завершается:

$ ch09-run ./ch09-run foo

usage: foo path arg() [ arg ... ]

Хотя она и не очень полезна, ch09-run ясно показывает, что argv[0] не обязательно должен иметь какое-нибудь отношение к файлу, который в действительности запускается.

В System III (примерно в 1980-м) команды cp, ln и mv представляли один исполняемый файл с тремя ссылками с этими именами в /bin. Программа проверяла argv[0] и решала, что она должна делать. Это сохраняло некоторое количество дискового пространства за счет усложнения исходного кода и форсирования выполнения программой действия по умолчанию при запуске с неизвестным именем. (Некоторые современные коммерческие системы Unix продолжают эту практику!) Без явной формулировки причин GNU Coding Standards рекомендует, чтобы программы не основывали свое поведение на своем имени. Одна причина, которую мы видели, состоит в том, что администраторы часто устанавливают GNU версию утилиты наряду со стандартной версией коммерческих систем Unix, используя префикс g: gmake, gawk и т.д. Если такие программы ожидают лишь стандартные имена, они при запуске с другим именем потерпят неудачу.

Сегодня также дисковое пространство дешево; если из одного и того же исходного кода можно построить две почти идентичные программы, лучше это сделать, использовав #ifdef, что у вас есть. Например, grep и egrep имеют значительную часть общего кода, но GNU версия строит два отдельных исполняемых файла.

9.1.4.4. Атрибуты, наследуемые exec()

Как и в случае с fork(), после вызова программой exec сохраняется ряд атрибутов:

• Все открытые файлы и открытые каталоги; см. раздел 4.4.1 «Понятие о дескрипторах файлов» и раздел 3.3.1 «Базовое чтение каталогов». (Сюда не входят файлы, помеченные для закрытия при исполнении (close-on-exec), как описано далее в этой главе; см. раздел 9.4.3.1 «Флаг close-on-exec».)

• Установки umask; см. раздел 4.6 «Создание файлов».

• Текущий рабочий каталог, см. раздел 8.4.1 «Изменение каталога: chdir() и fchdir()»

• Корневой каталог; см. раздел 8.6 «Изменение корневого каталога: chroot()».

• Текущее значение относительного приоритета.

• ID процесса и ID родительского процесса.

• ID группы процесса и контролирующий терминал; см. раздел 9.2.1 «Обзор управления работами».

• Маску сигналов процесса и любые ожидающие сигналы, а также любые не истекшие аварийные сигналы или таймеры (здесь не обсуждается; см. главу 10 «Сигналы»).

• Действительные ID пользователя и ID группы, а также дополнительный набор групп. Эффективные ID пользователя и группы (а следовательно, и сохраненные ID set-user и set-group) могут быть установлены с помощью битов setuid и setgid исполняемого файла. (Ничто из этого пока не обсуждалось; см. главу 11 «Права доступа и ID пользователя и группы».)

• Блокировки файлов сохраняются (также пока не обсуждалось; см. раздел 14.2 «Блокировка файлов»).

• Суммарное использованное время процессора для процесса и его потомков не меняется.

После exec размещение сигналов изменяется; дополнительные сведения см. в разделе 10.9 «Сигналы для fork() и exec()».

После exec все открытые файлы и каталоги остаются открытыми и доступными для использования. Вот как программы наследуют стандартные ввод, вывод и ошибку: они на месте, когда программа запускается.

В большинстве случаев при исполнении fork и exec для отдельной программы не нужно ничего наследовать, кроме дескрипторов файлов 0, 1 и 2. В этом случае можно вручную закрыть все другие открытые файлы в порожденном процессе после выполнения fork и до выполнения exec. В качестве альтернативы можно пометить дескриптор файла для автоматического закрытия системой при исполнении exec; эта последняя возможность обсуждается далее в главе (см раздел 9.4.3.1 «Флаг close-on-exec».)

9.1.5. Завершение процесса

Завершение процесса включает два шага: окончание процесса с передачей системе статуса завершения и восстановление информации родительским процессом.

9.1.5.1. Определение статуса завершения процесса

Статус завершения (exit status) (известный также под другими именами значения завершения (exit value), кода возврата (return code) и возвращаемого значения (return value)) представляет собой 8-битовое значение, которое родитель может использовать при завершении порожденного процесса (на языке Unix, «когда порожденный кончается (dies)»). По соглашению статус завершения 0 означает, что программа отработала без проблем. Любое ненулевое значение указывает на какую-нибудь разновидность ошибки; программа определяет используемые числа и их значения, если они есть. (Например, grep использует 0 для указания, что образец был встречен по крайней мере один раз, 1 означает, что образец вообще не встретился, а 2 означает, что возникла ошибка.) Этот статус завершения доступен на уровне оболочки (для оболочек в стиле оболочки Борна) через специальную переменную $?.

Стандарт С определяет две константы, которые следует использовать для полной переносимости на не-POSIX системы:

EXIT_SUCCESS

Программа завершилась без проблем. Для обозначения успеха может также использоваться ноль.

EXIT_FAILURE

В программе была какая-нибудь проблема.

На практике использование лишь этих значений довольно ограничивает. Вместо этого следует выбрать небольшой набор кодов возврата, документировать их значения и использовать. (Например, 1 для ошибок опций командной строки и аргументов, 2 для ошибок ввода/вывода, 3 для ошибок данных и т.д.) Для удобочитаемости стоит использовать константы #define или значения enum. Слишком большой список ошибок делает их использование обременительным; в большинстве случаев вызывающая программа (или пользователь) интересуется лишь нулевым или ненулевым значением.

Когда достаточно двоичного разделения успех/неудача, педантичный программист использует EXIT_SUCCESS и EXIT_FAILURE. Наш собственный стиль более естественный, используя с return и exit() явные константы 0 или 1. Это настолько обычно, что рано заучивается и быстро становится второй натурой. Однако для своих проектов вы сами должны принять решение.

ЗАМЕЧАНИЕ. Для родительского процесса доступны лишь восемь наименее значимых битов значения. Поэтому следует использовать значения в диапазоне 0–255. Как мы вскоре увидим, у чисел 126 и 127 есть традиционные значения (помимо простого «неуспешно»), которых ваши программы должны придерживаться.

Поскольку имеют значение лишь восемь наименее значимых битов, вы никогда не должны использовать отрицательные статусы завершения. Когда из небольших отрицательных чисел выделяются восемь последних битов, они превращаются в большие положительные значения! (Например. -1 становится 255, а -5 становится 251.) Мы видели книги по программированию на С, в которых это понималось неправильно — не дайте сбить себя с толку

9.1.5.2. Возвращение из main()

Программа может естественно завершиться одним из двух способов: посредством использования одной из описанных далее функций или возвратившись из main(). (Третий, более радикальный способ описан далее в разделе 12.4 «Совершение самоубийства: abort()».) В последнем случае следует использовать явное возвращаемое значение вместо выпадения в конце функции:

/* Правильно */                  /* Неправильно */

int main(int argc, char **argv)  int main(int argc, char **argv)

{                                {

 /* здесь код */                  /* здесь код */

 return 0;                        /* ?? Что возвращает main()? */

}                                }

Стандарт С 1999 г. указывает, что при выпадении в конце, поведение функции main() должно быть таким, как если бы она возвращала 0. (Это верно также для С++; однако, стандарт С 1989 г. намеренно оставляет этот случай неопределенным.) Во всех случаях плохо полагаться на это поведение; однажды вы можете программировать для системы соскудной поддержкой С времени исполнения, или для внедренной системы, или где-то еще, где это будет по-другому. (В общем, выпадение в конце любой функции, не являющейся void — плохая мысль, которая может вести лишь к ошибочному коду.)

Возвращенное из main() значение автоматически передается обратно системе, от которой родительский процесс может его впоследствии получить. Мы опишем, как это делается, в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».

ЗАМЕЧАНИЕ. На системах GNU/Linux управляемая компилятором команда c99 запускает компилятор с соответствующими опциями, так что возвращаемое значение при выпадении из конца функции равно 0. Простой gcc этого не делает.

9.1.5.3. Функции завершения

Другим способом естественного завершения программы является вызов функций завершения. Стандарт С определяет следующие функции:

#include <stdlib.h> /* ISO С */


void exit(int status);

void _Exit(int status);

int atexit(void (*function)(void));

Эти функции работают следующим образом:

void exit(int status)

Эта функция завершает программу, status передается системе для использования родителем. Перед завершением программы exit() вызывает все функции, зарегистрированные с помощью atexit(), сбрасывает на диск и закрывает все открытые потоки <stdio.h> FILE* и удаляет все временные файлы, созданные tmpfile() (см. раздел 12.3.2 «Создание и открытие временных файлов»). Когда процесс завершается, ядро закрывает любые оставшиеся открытыми файлы (которые были открыты посредством open(), creat() или через наследование дескрипторов), освобождает его адресное пространство и освобождает любые другие ресурсы, которые он мог использовать. exit() никогда не возвращается.

void _Exit(int status)

Эта функция в сущности идентична функции POSIX _exit(); мы на короткое время отложим ее обсуждение,

int atexit(void (*function)(void))

function является указателем на функцию обратного вызова, которая должна вызываться при завершении программы, exit() запускает функцию обратного вызова перед закрытием файлов и завершением. Идея в том, что приложение может предоставить одну или более функций очистки, которые должны быть запущены перед окончательным завершением работы. Предоставление функции называется ее регистрацией. (Функции обратного вызова для nftw() обсуждались в разделе 8.4.3.2 «Функция обратного вызова nftw()»; здесь та же идея, хотя atexit() вызывает каждую зарегистрированную функцию лишь однажды.)

atexit() возвращает 0 при успехе или -1 при неудаче и соответствующим образом устанавливает errno.

Следующая программа не делает полезной работы, но демонстрирует, как работает atexit():

/* ch09-atexit.c --- демонстрация atexit().

   Проверка ошибок для краткости опущена. */

/*

 * Функции обратного вызова здесь просто отвечают на вызов.

 * В настоящем приложении они делали бы больше. */

void callback1(void) { printf("callback1 called\n"); }

void callback2(void) { printf("callback2 called\n"); }

void callback3(void) { printf("callback3 called\n"); }


/* main --- регистрация функций и завершение */

int main(int argc, char **argv) {

 printf("registering callback1\n"); atexit(callback1);

 printf("registering callback2\n"); atexit(callback2);

 printf("registering callback3\n"); atexit(callback3);

 printf("exiting now\n");

 exit(0);

}

Вот что происходит при запуске:

$ ch09-atexit

registering callback1 /* Запуск главной программы */

registering callback2

registering callback3

exiting now

callback3 called /* Функции обратного вызова запускаются в обратном

                    порядке */

callback2 called

callback1 called

Как показывает пример, функции, зарегистрированные с помощью atexit(), запускаются в порядке, обратном порядку их регистрации: последние первыми. (Это обозначается также LIFO — last-in-first-out — вошедший последним выходит первым).

POSIX определяет функцию _exit(). В отличие от exit(), которая вызывает функции обратного вызова и выполняет <stdio.h>-очистку, _exit() является «сразу заканчивающейся» функцией:

#include <unistd.h> /* POSIX */


void _exit(int status);

Системе передается status, как и для exit(), но процесс завершается немедленно. Ядро все еще делает обычную очистку: все открытые файлы закрываются, использованная адресным пространством память освобождается, любые другие ресурсы, использованные процессом, также освобождаются.

На практике функция _Exit() ISO С идентична _exit(). Стандарт С говорит, что от реализации функции зависит, вызывает ли _Exit() зарегистрированные atexit() функции и закрывает ли открытые файлы. Для систем GLIBC это не так, и функция ведет себя подобно _exit().

Время использовать _exit() наступает, когда exec в порожденном процессе завершается неудачей. В этом случае вам не нужно использовать обычный exit(), поскольку это сбрасывает на диск данные буферов, хранящиеся в потоках FILE*. Когда позже родительский процесс сбрасывает на диск свои копии буферов, данные буфера оказываются записанными дважды; это очевидно нехорошо.

Например, предположим, что вы хотите запустить команду оболочки и хотите сами выполнить fork и exec. Такой код выглядел бы следующим образом:

char *shellcommand = "...";

pid_t child;

if ((child = fork()) == 0) { /* порожденный процесс */

 execl("/bin/sh", "sh", "-c", shellcommand, NULL);

 _exit(errno == ENOENT ? 127 : 126);

}

/* родитель продолжает */

Проверка значения errno и завершающего значения следуют соглашениям, используемым оболочкой POSIX. Если запрошенная программа не существует (ENOENT — нет для неё элемента в каталоге), завершающее значение равно 127. В противном случае, файл существует, но exec не могла быть выполнена по какой-то другой причине, поэтому статус завершения равен 126. Хорошая мысль следовать этим соглашениям также и в ваших программах. Вкратце, чтобы хорошо использовать exit() и atexit(), следует делать следующее:

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

• Решить, имеет ли смысл наличие функций обратного вызова для использования с atexit(). Если имеет, зарегистрировать их в main() в соответствующий момент; например, после анализа опций и инициализации всех структур данных, которые функция обратного вызова должна очищать. Помните, что функции должны вызываться в порядке LIFO (последняя вызывается первой).

• Использовать exit() для выхода из программы во всех местах, когда что-то идет не так и когда выход является правильным действием. Используйте коды ошибок, которые определили.

• Исключением является main(), для которой можно использовать при желании return. Наш собственный стиль заключается обычно в использовании exit() при наличии проблем и 'return 0' в конце main(), если все прошло хорошо.

• Использовать _exit() или _Exit() в порожденном процессе, если exec() завершается неудачей.

9.1.6. Использование статуса завершения порожденного процесса

Когда процесс заканчивается, нормальным ходом событий для ядра является освобождение всех его ресурсов. Ядро сохраняет статус завершения законченного процесса, также, как сведения о ресурсах, которые он использовал в своей работе, a PID продолжает считаться используемым. Такой завершившийся процесс называется зомби.

Родительский процесс, будь то первоначальный родитель или init, может получить статус завершения порожденного процесса. Или, посредством использования функций BDS, которые не стандартизованы POSIX, можно получить статус завершения вместе со сведениями об использовании ресурсов. Использование статуса осуществляется ожиданием окончания процесса: это известно также как пожинание (reaping) процесса[91].

Между механизмами, которые ожидают завершения потомков, и сигнальными механизмами, которые мы еще не обсуждали, есть значительное взаимодействие. Что из них описать вначале представляет собой нечто вроде проблемы курицы и яйца; мы решили сначала поговорить сначала о механизмах ожидания порожденного процесса, а глава 10 «Сигналы» дает полный рассказ о сигналах.

Пока достаточно понять, что сигнал является способом уведомления процесса о том, что произошло некоторое событие. Процессы могут генерировать сигналы, которые посылаются самим себе, или сигналы могут посылаться извне другими процессами или пользователем за терминалом. Например, CTRL-C посылает сигнал «прерывания», a CTRL-Z посылает сигнал управления работой «стоп».

По умолчанию, многие сигналы, такие, как сигнал прерывания, заставляют получающий процесс закончиться. Другие, такие, как сигналы управления работами, вызывают изменение его состояния. Механизмы ожидания порожденного процесса могут определить, претерпел ли процесс сигнал завершения, и если да, какой это был сигнал. То же верно и для остановки процесса и, на некоторых системах возобновления процесса.

9.1.6.1. Использование функций POSIX: wait() и waitpid()

Первоначальным системным вызовом V7 был wait(). Более новым вызовом POSIX, основанным на возможностях BSD, является waitpid(). Объявления функций следующие:

#include <sys/types.h> /* POSIX */

#include <sys/wait.h>


pid_t wait(int *status);

pid_t waitpid(pid_t pid, int *status, int options);

wait() ждет завершения любого порожденного процесса; сведения о том, как он завершился, возвращаются в *status. (Вскоре мы обсудим, как интерпретировать *status.) Возвращаемое значение является PID завершившегося процесса или -1, если возникла ошибка.

Если порожденных процессов нет, wait() возвращает -1 с errno, установленным в ECHILD (отсутствует порожденный процесс). В противном случае, функция ждет завершения первого порожденного процесса или поступления сигнала.

Функция waitpid() дает возможность ждать завершения определенного порожденного процесса. Она предоставляет значительную гибкость и является предпочтительной для использования функцией. Она также возвращает PID закончившегося процесса или -1 при возникновении ошибки. Аргументы следующие:

pid_t pid

Значение указывает, завершения какого порожденного процесса ждать как по-настоящему pid, так и по группе процесса. Смысл значения pid следующий:

pid < -1 Ждать завершения любого порожденного процесса с ID группы процесса, равной абсолютному значению pid.

pid = -1 Ждать завершения любого порожденного процесса. Таким способом работает wait().

pid = 0  Ждать завершения любого порожденного процесса с ID группы процесса, равной ID группе родительского процесса.

pid > 0  Ждать завершения конкретного процесса с PID, равным pid.

int *status

То же, что и для wait(). <sys/wait.h> определяет различные макросы, которые интерпретируют значение в *status, которые мы вскоре опишем

int options

Этот параметр должен быть равен либо 0, либо побитовым ИЛИ одного или более из следующих флагов:

 WNOHANG

 Если ни один порожденный процесс не завершился, вернуться немедленно. Таким способом можно периодически проверять, не закончился ли какой- нибудь порожденный процесс. (Такая периодическая проверка известна как опрашивание события.)

 WUNTRACED

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

 WCONTINUED

 (XSI.) Вернуть сведения о порожденном процессе, который продолжился, если его статус не сообщался с момента изменения. Это также для управления работой. Этот флаг является расширением XSI и не доступен под GNU/Linux.

С заполненным значением *status работают несколько макросов, определяющие, что случилось. Они имеют тенденцию образовывать пары: один макрос для определения, что что-то случилось, и если этот макрос истинен, еще один макрос позволяет получить подробности. Макросы следующие:

WIFEXITED(status)

Этот макрос не равен нулю (true), если процесс завершился (в противоположность изменению состояния).

WEXITSTATUS(status)

Этот макрос дает статус завершения; он равен восьми наименее значимым битам значения, переданного exit() или возвращенного из main(). Этот макрос следует использовать лишь если WIFEXIDED(status) равен true.

WIFSIGNALED(status)

Этот макрос не равен нулю, если процесс подвергся действию завершающего сигнала death-by-signal.

WTERMSIG(status)

Этот макрос предоставляет номер сигнала, который завершил процесс. Этот макрос следует использовать, лишь когда WIFSIGNALED(status) равен true.

WIFSTOPPED(status)

Этот макрос не равен нулю, если процесс был остановлен.

WSTOPSIG(status)

Этот макрос предоставляет номер сигнала, который остановил процесс. (Процесс остановить могут несколько сигналов.) Этот макрос следует использовать лишь когда WIFSTOPPED(status) равен true. Сигналы управления работами обсуждаются в разделе 10.8.2 «Сигналы управления работой».

WIFCONTINUED(status)

(XSI.) Этот макрос не равен нулю, если процесс был продолжен. Соответствующего макроса WCONTSIG() нет, поскольку лишь один сигнал может вызвать продолжение процесса.

Обратите внимание, что этот макрос является расширением XSI и в частности, он недоступен в GNU/Linux. Следовательно, если вы хотите его использовать, заключите код внутри '#ifdef WIFCONTINUED ... #endif'.

WCOREDUMP(status)

(Общий.) Этот макрос не равен нулю, если процесс создал снимок. Снимок процесса (core dump) является образом запущенного процесса в памяти, созданном при завершении процесса. Он предназначен для использования впоследствии при отладке. Системы Unix называют файл core, тогда как системы GNU/Linux используют corе.pid, где pid является ID завершившегося процесса. Определенные сигналы завершают процесс и автоматически создают снимок процесса.

Обратите внимание, что этот макрос не стандартный. Системы GNU/Linux, Solaris и BSD его поддерживают, однако некоторые другие системы Unix нет. Поэтому и здесь, если нужно его использовать, заключите код внутрь '#ifdef WCOREDUMP ... #endif'.

Большинство программ не интересуются, почему завершился порожденный процесс; им просто нужно, что он завершился, возможно, отметив, было завершение успешным или нет. Программа GNU Coreutils install демонстрирует такое простое использование fork(), execlp() и wait(). Опция -s заставляет install запустить для устанавливаемого двоичного исполняемого файла программу strip. (strip удаляет из исполняемого файла отладочную и прочую информацию. Это может сохранить значительное пространство. На современных системах с многогигабайтными жесткими дисками при установке редко бывает необходимо использовать strip для исполняемых файлов.) Вот функция strip() из install.с:

513 /* Вырезать таблицу имен из файла PATH.

514    Мы могли бы сначала вытащить из файла магическое число

515    для определения, нужно ли вырезать, но заголовочные файлы и

516    магические числа варьируют от системы к системе так сильно, что

517    сделать его переносимым было бы очень трудно. Не стоит усилий. */

518

519 static void

520 strip (const char *path)

521 {

522  int status;

523  pid_t pid = fork();

524

525  switch (pid)

526  {

527  case -1:

528   error(EXIT_FAILURE, errno, _("fork system call failed"));

529   break;

530  case 0: /* Порожденный. */

531   execlp("strip", "strip", path, NULL);

532   error(EXIT_FAILURE, errno, _("cannot run strip"));

533   break;

534  default: /* Родитель. */

535   /* Родительский процесс. */

536   while (pid != wait(&status)) /* Ждать завершения потомка. */

537    /* Ничего не делать. */ ;

538   if (status)

539    error(EXIT_FAILURE, 0, _("strip failed"));

540   break;

541  }

542 }

Строка 523 вызывает fork(). Затем оператор switch предпринимает нужное действие для возвращения ошибки (строки 527–529), порожденного процесса (строки 530–533) и родительского процесса (строки 534–539).

Стиль строк 536–537 типичен; они ожидают завершения нужного порожденного процесса. Возвращаемое значение wait() является PID этого потомка. Оно сравнивается с PID порожденного процесса, status проверяется лишь на предмет равенства нулю (строка 538), в случае ненулевого результата потомок завершился неудачно. (Тест, хотя и правильный, грубый, но простой. Более правильным был бы тест наподобие 'if (WIFEXITED(status) && WEXITSTATUS(status) != 0)'.)

Из описаний и кода, представленных до сих пор, может показаться, что родительские программы должны выбрать определенный момент, чтобы ожидать завершения любого порожденного процесса, возможно, с опросом в цикле (как делает install.c), ожидая всех потомков. В разделе 10.8.3 «Родительский надзор: три различные стратегии» мы увидим, что это необязательно. Скорее, сигналы предоставляют ряд механизмов для использования уведомлениями родителей о завершении порожденных процессов.

9.1.6.2. Использование функций BSD: wait3() и wait4()

Системные вызовы BSD wait3() и wait4() полезны, если вы интересуетесь ресурсами, использованными порожденным процессом. Функции нестандартны (что означает, что они не являются частью POSIX), но широко доступны, в том числе на GNU/Linux. Объявления следующие:

#include <sys/types.h> /* Обычный */

#include <sys/time.h>

 /* Под GNU/Linux не нужно, но улучшает переносимость */

#include <sys/resource.h>

#include <sys/wait.h>


pid_t wait3(int *status, int options, struct rusage *rusage);

pid_t wait4(pid_t pid, int *status, int options, struct rusage *rusage);

Переменная status та же, что и для wait() и waitpid(). Все описанные ранее макросы (WIFEXITED() и т.д.) могут использоваться и с ними.

Значение options также то же самое, что и для waitpid(): либо 0, либо побитовое ИЛИ с одним или обоими флагами WNOHANG и WUNTRACED.

wait3() ведет себя подобно wait(), получая сведения о первом доступном порожденном зомби, a wait4() подобна waitpid(), получая сведения об определенном процессе. Обе функции возвращают PID потомка, -1 при ошибке или 0, если нет доступных процессов и был использован флаг WNOHANG. Аргумент pid может принимать те же значения, что и аргумент pid для waitpid().

Ключевым отличием является указатель struct rusage. Если он не равен NULL, система заполняет ее сведениями о процессе. Эта структура описана в POSIX и в справочной странице getrusage(2):

struct rusage {

 struct timeval ru_utime; /* используемое время пользователя */

 struct timeval ru_stime; /* используемое системное время */

 long ru_maxrss;   /* максимальный размер резидентного набора */

 long ru_ixrss;    /* общий размер разделяемой памяти */

 long ru_idrss;    /* общий размер не разделяемых данных */

 long ru_isrss;    /* общий размер не разделяемого стека */

 long ru_minflt;   /* использование страниц */

 long ru_majflt;   /* ошибок страниц */

 long ru_nswap;    /* подкачек */

 long ru_inblock;  /* блочных операций ввода */

 long ru_oublock;  /* блочных операций вывода */

 long ru_msgsnd;   /* посланных сообщений */

 long ru_msgrcv;   /* полученных сообщений */

 long ru_nsignals; /* полученных сигналов */

 long ru_nvcsw;    /* добровольных переключений контекста */

 long ru_nivcsw;   /* принудительных переключений контекста */

};

Чисто BSD системы (4.3 Reno и более поздние) поддерживают все поля. В табл. 9.2 описаны доступность различных полей struct rusage для POSIX и Linux.


Таблица 9.2. Доступность полей struct rusage

Поле POSIX Linux Поле POSIX Linux
ru_utime ≥ 2.4 ru_nswap ≥2.4
ru_stime ≥2.4 ru_nvcsw ≥2.6
ru_minflt ≥2.4 ru_nivcsw ≥2.6
ru_majflt ≥2.4
Стандартом определены лишь поля, помеченные «POSIX». Хотя Linux определяет полную структуру, ядро 2.4 поддерживает лишь поля времени пользователя и системного времени. Ядро 2.6 поддерживает также поля, связанные с переключением контекста.[92]

Наиболее интересными полями являются ru_utime и ru_stime, использование времени процессора в режиме пользователя и ядра соответственно. (Время процессора в режиме пользователя является временем, потраченным на исполнение кода уровня пользователя. Время процессора в режиме ядра является временем, потраченным в ядре в пользу процесса.)

Эти два поля используют struct timeval, которая содержит значения времени с точностью до микросекунд. Дополнительные сведения по этой структуре см. в разделе 14.3.1 «Время в микросекундах: gettimeofday()».

В BSD 4.2 и 4.3 аргумент status функций wait() и wait3() был union wait. Он умещался в int и предоставлял доступ к тем же сведениям, которые выдают современные макросы WIFEXITED() и др., но через членов объединения. Не все члены были действительными во всех случаях. Эти члены и их использование описаны в табл. 9.3.


Таблица 9.3. union wait 4.2 и 4.3 BSD

Макрос POSIX Член объединения Использование Значение
WIFEXITED() w_termsig w.w_termsig == 0 True при нормальном завершении
WEXITSTATUS() w_retcode code = w.w_retcode Статус завершения, если не по сигналу
WIFSIGNALED() w_termsig w.w_temsig != 0 True, если завершен по сигналу
WTERMSIG() w_termsig sig = w.w_termsig Сигнал, вызвавший завершение
WIFSTOPPED() w_stopval w.w_stopval == WSTOPPED True, если остановлен
WSTOPSIG() w_stopsig sig = w.w_stopsig Сигнал, вызвавший остановку
WCOREDUMP() w_coredump w.w_coredump != 0 True, если потомок сделал снимок образа
POSIX не стандартизует union wait, a BSD 4.4 не документирует его, используя вместо этого макросы POSIX. GLIBC делает несколько бросков, чтобы заставить использующий его старый код продолжать работать. Мы опишем его здесь главным образом для того, чтобы вы увидев его — узнали; новый код должен использовать макросы, описанные в разделе 9.1.6.1 «Использование функций POSIX: wait() и waitpid()».

9.2. Группы процессов

Группа процесса является группой связанных процессов, которые в целях управления заданием (job) рассматриваются вместе. Процессы с одним и тем же ID группы процессов являются членами группы процессов, а процесс, PID которого равен ID группы процессов, является лидеров группы процессов. Новые процессы наследуют ID группы процессов своих родительских процессов.

Мы уже видели, что waitpid() позволяет вам ждать любой процесс в данной группе процессов. В разделе 10.6.7 «Отправка сигналов: kill() и killpg()» мы увидим также, что вы можете отправить сигнал всем процессам в определенной группе процессов. (Всегда применяется проверка прав доступа; вы не можете послать сигнал процессу, которым не владеете.)

9.2.1. Обзор управления заданиями

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

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

Сеанс (session) является коллекцией групп процессов, связанных с управляющим терминалом. На одном терминале имеется лишь один сеанс, с несколькими группами процессов в сеансе. Один процесс назначен лидером сеанса; обычно это оболочка, такая, как Bash, pdksh, zsh или ksh93[93], которая может осуществлять управление заданиями. Мы называем такую оболочку оболочкой, управляющей заданиями.

Каждое задание, запущенное управляющей заданиями оболочкой, будь то простая программа или конвейер, получает отдельный идентификатор группы процессов. Таким способом оболочка может манипулировать заданием как отдельной сущностью, хотя в нем может быть несколько процессов.

Управляющий терминал также имеет связанный с ним идентификатор группы процессов. Когда пользователь набирает специальный символ, такой, как CTRL-C для «прерывания» или CTRL-Z для «остановки», ядро посылает данный сигнал процессам в группе процессов терминала.

Группе процессов, ID которой совпадает с ID управляющего терминала, разрешено записывать в терминал и читать с него. Эта группа называется приоритетной (foreground) группой процессов. (Она получает также генерируемые клавиатурой сигналы.) Любые другие группы процессов в сеансе являются фоновыми (background) группами процессов и не могут читать или записывать в терминал; они получают специальные сигналы, которые их останавливают, если они пытаются это делать.

Задания переходят из приоритетного режима в фоновый и обратно не путем изменения атрибута задания, но посредством изменения группы процессов управляющего терминала. Это изменение осуществляет именно контролирующая задания оболочка, и если новая группа процессов останавливается, оболочка вновь запускает ее, посылая сигнал «продолжить» всем членам группы процессов.

В былые времена пользователи часто использовали последовательные терминалы, соединенные с модемами, для подключения к централизованным Unix-системам на мини-компьютерах. Когда пользователь закрывал соединение (вешал трубку), линия последовательной передачи обнаруживала отсоединение, и ядро посылало сигнал «отсоединение» всем подключенным к терминалу процессам.

Эта концепция остается: если возникает отключение (оборудование последовательной связи все еще существует и все еще используется), ядро посылает сигнал отсоединения приоритетной группе процессов. Если существует лидер сеанса, происходит то же самое.

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

9.2.2. Идентификация группы процессов: getpgrp() и getpgid()

Для совместимости с более старыми системами POSIX предоставляет множество способов получения сведений о группе процессов:

#include <unistd.h>


pid_t getpgrp(void);      /* POSIX */

pid_t getpgid(pid_t pid); /* XSI */

Функция getpgrp() возвращает ID группы процессов текущего процесса. getpgid() является расширением XSI. Она возвращает ID группы процессов для данного pid группы процессов. pid, равный 0, означает «группа процессов текущего процесса». Таким образом, 'getpgid(0)' является тем же самым, что и 'getpgrp()'. При обычном программировании следует использовать getpgrp().

В BSD 4.2 и 4.3 также есть функция getpgrp(), но она действует как функция POSIX getpgid(), требуя аргумент pid. Поскольку современные системы поддерживают POSIX, в новом коде следует использовать версию POSIX. (Если вы думаете, что это сбивает с толку, вы правы. Несколько способов для получения одного и того же результата является обычным итогом проектирования комитетом, поскольку комитет считает, что он должен удовлетворить каждого.)

9.2.3. Установка группы процесса: setpgid() и setpgrp()

Две функции устанавливают группу процесса:

#include <unistd.h>


int setpgid(pid_t pid, pid_t pgid); /* POSIX */

int setpgrp(void);                  /* XSI */

Функция setpgrp() проста: она устанавливает ID группы процесса равной ID процесса. Это создает новую группу процессов в том же сеансе, а вызывающий функцию процесс становится лидером группы процессов.

Функция setpgid() предназначена для использования управления заданиями. Она позволяет одному процессу устанавливать группу процесса для другого. Процесс может изменить лишь свой собственный ID группы процессов или ID группы процессов порожденного процесса, лишь если этот порожденный процесс не выполнил еще exec. Управляющая заданиями оболочка делает этот вызов после fork как в родительском, так и в порожденном процессах. Для одного из них вызов завершается успехом, и ID группы процессов изменяется. (В противном случае нет способа гарантировать упорядочение, когда родитель может изменить ID группы процессов порожденного процесса до того, как последний выполнит exec. Если сначала успешно завершится вызов родителя, он может перейти на следующую задачу, такую, как обработка других заданий или управление терминалом.)

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

Имеется несколько значений для особых случаев как для pid, так и для pgid:

pid = 0 В данном случае setpgid() изменяет группу процессов вызывающего процесса на pgid. Это эквивалентно 'setpgid(getpid(), pgid)'.

pgid = 0 Это устанавливает ID группы процессов для данного процесса равным его PID. Таким образом, 'setpgid(pid, 0)' является тем же самым, что и 'setpgid(pid, pid)'. Это делает процесс с PID, равным pid, лидером группы процессов.

Во всех случаях лидеры сеанса являются особыми; их PID, ID группы процессов и ID сеанса идентичны, a ID группы процессов лидера не может быть изменена. (ID сеанса устанавливаются посредством setsid(), а получаются посредством getsid(). Это особые вызовы: см. справочные страницы setsid(2) и getsid(2)).

9.3. Базовое межпроцессное взаимодействие: каналы и очереди FIFO

Межпроцессное взаимодействие (Interprocess communication — IPC) соответствует своему названию: это способ взаимодействия для двух отдельных процессов. Самым старым способом IPC на системах Unix является канал (pipe): односторонняя линия связи. Данные, записанные в один конец канала, выходят из другого конца.

9.3.1. Каналы

Каналы проявляют себя как обычные дескрипторы файлов. Без особого разбирательства вы не можете сказать, представляет ли дескриптор файла сам файл или канал. Это особенность; программы, которые читают из стандартного ввода и записывают в стандартный вывод, не должны знать или заботиться о том, что они могут взаимодействовать с другим процессом. Если хотите знать, каноническим способом проверки этого является попытка выполнить с дескриптором 'lseek(fd, 0L, SEEK_CUR)'; этот вызов пытается отсчитать 0 байтов от текущего положения, т е. операция, которая ничего не делает[94]. Эта операция завершается неудачей для каналов и не наносит никакого вреда другим файлам.

9.3.1.1. Создание каналов

Системный вызов pipe() создает канал:

#include <unistd.h> /* POSIX */


int pipe(int filedes[2]);

Значение аргумента является адресом массива из двух элементов целого типа, pipe() возвращает 0 при успешном возвращении и -1, если была ошибка.

Если вызов был успешным, у процесса теперь есть два дополнительных открытых дескриптора файла. Значение filedes[0] является читаемым концом канала, a filedes [1] — записываемым концом. (Удобным мнемоническим способом запоминания является то, что читаемый конец использует индекс 0, аналогичный дескриптору стандартного ввода 0, а записываемый конец использует индекс 1, аналогичный дескриптору стандартного вывода 1.)

Как упоминалось, данные, записанные в записываемый конец, считываются из читаемого конца. После завершения работы с каналом оба конца закрываются с помощью вызова close(). Следующая простая программа, ch09-pipedemo.c, демонстрирует каналы путем создания канала, записи в него данных, а затем чтения этих данных из него:

1  /* ch09-pipedemo.c --- демонстрация ввода/вывода с каналом. */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <unistd.h>

6

7  /* main --- создание канала, запись в него и чтение из него. */

8

9  int main(int argc, char **argv)

10 {

11  static const char mesg[] = "Don't Panic!"; /* известное сообщение */

12  char buf[BUFSIZ];

13  ssize_t rcount, wcount;

14  int pipefd[2];

15  size_t l;

16

17  if (pipe(pipefd) < 0) {

18   fprintf(stderr, "%s: pipe failed: %s\n", argv[0],

19    strerror(errno));

20   exit(1);

21  }

22

23  printf("Read end = fd %d, write end = fd %d\n",

24   pipefd[0], pipefd[1]);

25

26  l = strlen(mesg);

27  if ((wcount = write(pipefd[1], mesg, 1)) != 1) {

28   fprintf(stderr, "%s: write failed: %s\n", argv[0],

29    strerror(errno));

30   exit(1);

31  }

32

33  if ((rcount = read(pipefd[0], buf, BUFSIZ)) != wcount) {

34   fprintf(stderr, "%s: read failed: %s\n", argv[0],

35    strerror(errno));

36   exit(1);

37  }

38

39  buf[rcount] = '\0';

40

41  printf("Read <%s> from pipe\n", buf);

42  (void)close(pipefd[0]);

43  (void)close(pipefd[1]);

44

45  return 0;

46 }

Строки 11–15 объявляют локальные переменные; наибольший интерес представляет mesg, который представляет текст, проходящий по каналу.

Строки 17–21 создают канал с проверкой ошибок; строки 23–24 выводят значения новых дескрипторов файлов (просто для подтверждения, что они не равны 0, 1 или 2)

В строке 26 получают длину сообщения для использования с write(). Строки 27–31 записывают сообщение в канал, снова с проверкой ошибок.

Строки 33–37 считывают содержимое канала, опять с проверкой ошибок. Строка 39 предоставляет завершающий нулевой байт, так что прочитанные данные могут использоваться в качестве обычной строки. Строка 41 выводит данные, а строки 42–43 закрывают оба конца канала. Вот что происходит при запуске программы:

$ ch09-pipedemo

Read end = fd 3, write end = fd 4

Read <Don't Panic!> from pipe

Эта программа не делает ничего полезного, но она демонстрирует основы. Обратите внимание, что нет вызовов open() или creat() и что программа не использует три своих унаследованных дескриптора. Тем не менее, write() и read() завершаются успешно, показывая, что дескрипторы файлов действительны и что данные, поступающие в канал, действительно выходят из него.[95] Конечно, будь сообщение слишком большим, наша программа не работала бы. Это происходит из-за того, что размер (памяти) каналов ограничен, факт, который мы обсудим в следующем разделе.

Подобно другим дескрипторам файлов, дескрипторы для каналов наследуются порожденным процессом после fork, и если они не закрываются, все еще доступны после exec. Вскоре мы увидим, как использовать это обстоятельство и сделать с каналами что-то интересное.

9.3.1.2. Буферирование каналов

Каналы буферируют свои данные, что означает, что записанные в канал данные хранятся ядром до тех пор, пока не будут прочитаны. Однако, канал может содержать лишь такое-то количество записанных, но еще не прочитанных данных. Мы можем называть записывающий процесс производителем, а читающий процесс потребителем. Как система управляет полными и пустыми каналами?

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

Подобным же образом, если канал пустой, потребитель блокируется в read() до тех пор, пока в канале не появятся данные для чтения. (Блокирующее поведение можно отключить; это обсуждается в разделе 9.4.3.4 «Неблокирующий ввод/вывод для каналов и очередей FIFO».)

Когда производитель вызывает на записывающем конце канала close(), потребитель может успешно прочесть любые данные, все еще находящиеся в канале. После этого дальнейшие вызовы read() возвращают 0, указывая на конец файла.

Напротив, если потребитель закрывает читаемый конец, write() на записываемом конце завершается неудачей. В частности, ядро посылает производителю сигнал «нарушенный канал», действием по умолчанию для которого является завершение процесса.

Нашей любимой аналогией для каналов является то, как муж и жена вместе моют и сушат тарелки. Один супруг моет тарелки, помещая чистые, но влажные тарелки в сушилку на раковине. Другой супруг вынимает тарелки из сушилки и вытирает их. Моющий тарелки является производителем, сушилка является каналом, а вытирающий является потребителем.[96]

Если вытирающий супруг оказывается быстрее моющего, сушилка становится пустой, и вытирающему приходится ждать, пока не будут готовы новые тарелки. Напротив, если быстрее вытирающий супруг, сушилка наполняется, и моющему приходится ждать, пока она не опустеет, прежде чем помещать в нее тарелки. Это изображено на рис. 9.3.

Рис. 9.3. Синхронизация процессов канала

9.3.2. Очереди FIFO

Для традиционных каналов единственным способом для двух различных программ получить доступ к одному и тому же каналу является наследование дескрипторов файлов. Это означает, что процессы должны быть порожденными от общего родителя или один должен быть предком другого.

Это может быть серьезным ограничением. Многие системные службы запускаются как демоны, отсоединенные долгоживущие процессы. Должен быть способ отправки данных таким процессам (и, возможно, получения данных от них). Файлы для этого не подходят; синхронизация трудна или невозможна, а каналы для выполнения задания не могут быть созданы, поскольку нет общих предков.

Для решения этой проблемы System III предложила идею о FIFO. FIFO,[97] или именованный канал, является файлом в файловой системе, который действует подобно каналу. Другими словами, один процесс открывает FIFO для записи, тогда как другой открывает его для чтения. Затем данные, записанные; в FIFO, читаются читателем. Данные буферируются ядром, а не хранятся на диске.

Рассмотрите спулер печати. Демон спулера управляет физическими принтерами, создавая задания для печати и печатая по одному заданию за раз. Для добавления в очередь задания программное обеспечение принтера на уровне пользователя должно сообщаться с демоном спулера. Одним способом для осуществления этого является создание спулером FIFO с хорошо известным именем файла. Программа пользователя может затем открыть FIFO, записать в него запрос и снова закрыть. Спулер находится в цикле, читая запросы из FIFO и обрабатывая их.

Функция mkfifo() создает файлы FIFO:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>


int mkfifo(const char *pathname, mode_t mode);

Аргумент pathname является именем создаваемого FIFO, a mode является данными ему правами доступа, аналогичными второму аргументу функции creat() или третьему аргументу функции open() (см. раздел 4.6 «Создание файлов»). Файлы FIFO удаляются, как любые другие, с помощью remove() или unlink() (см. раздел 5.1.5.1 «Удаление открытых файлов»).

Справочная страница GNU/Linuxmkfifo(3) указывает, что FIFO должен быть открыт как для чтения, так и для записи в одно и то же время, до того, как может быть осуществлен ввод/вывод: «Открытие FIFO для чтения обычно блокирует до тех пор, пока какой-нибудь другой процесс не откроет тот же FIFO для записи, и наоборот». После открытия файла FIFO он действует подобно обычному каналу; т.е. это просто еще один дескриптор файла.

Команда mkfifo доставляет этот системный вызов на командный уровень. Это упрощает показ файла FIFO в действии:

$ mkfifo afifo /* Создание файла FIFO */

$ ls -l afifo

 /* Показать тип и права доступа, обратите внимание на 'p' впереди */

prw-r--r-- 1 arnold devel 0 Oct 23 15:49 afifo

$ cat < afifo & /* Запустить читателя в фоновом режиме */

[1] 22100

$ echo It was a Blustery Day > afifo /* Послать данные в FIFO */

$ It was a Blustery Day /* Приглашение оболочки, cat выводит данные */

 /* Нажмите ENTER, чтобы увидеть статус завершения задания */

[1]+ Done cat <afifo /* cat завершился */

9.4. Управление дескрипторами файлов

На данный момент части загадки почти полностью составлены, fork() и exec() создают процессы и запускают в них программы, pipe() создает канал, который может использоваться для IPC. Чего до сих пор не хватает, так это способа помещения дескрипторов канала на место стандартных ввода и вывода для производителя и потребителя канала.

Системные вызовы dup() и dup2(), совместно с close() дают вам возможность поместить (скопировать) открытый дескриптор файла на другой номер. Системный вызов fcntl() дает вам возможность то же самое и управлять несколькими важными атрибутами открытых файлов.

9.4.1. Дублирование открытых файлов: dup() и dup2()

Два системных вызова создают копию открытого дескриптора файла:

#include <unistd.h> /* POSIX */


int dup(int oldfd);

int dup2(int oldfd, int newfd);

Функции следующие:

int dup(int oldfd)

Возвращает наименьшее значение неиспользуемого дескриптора файла; это копия oldfd. dup() возвращает неотрицательное целое в случае успеха и -1 при неудаче.

int dup2(int oldfd, int newfd)

Делает newfd копией oldfd; если newfd открыт, он сначала закрывается, как при использовании close(). dup2() возвращает новый дескриптор или -1, если была проблема. Помните рис. 9.1, в котором два процесса разделяли общие указатели на один и тот же элемент файла в таблице файлов ядра? dup() и dup2() создают ту же ситуацию внутри одного процесса. См. рис. 9.4.

Рис. 9.4. Разделение дескриптора файла как результат 'dup2(1, 3)'

На этом рисунке процесс выполнил 'dup2(1, 3)', чтобы сделать дескриптор файла 3-й копией стандартного вывода, дескриптора файла 1. Точно как описано ранее, эти два дескриптора разделяют общее смещение открытого файла.

В разделе 4.4.2 «Открытие и закрытие файлов» мы упомянули, что open()creat()) всегда возвращают наименьшее целое значение неиспользуемого дескриптора для открываемого файла. Этому правилу следуют почти все системные вызовы, которые возвращают новые дескрипторы файлов, а не только open() и creat(). (dup2() является исключением, поскольку он предусматривает способ получения конкретного нового дескриптора файла, даже если он не является наименьшим неиспользуемым дескриптором.)

При наличии правила «возвращения наименьшего неиспользуемого номера» в сочетании с функцией dup() теперь легко поместить дескрипторы файла канала на место стандартного ввода и вывода. В предположении, что текущим процессом является оболочка и что ей необходимо создать два порожденных процесса для образования двухступенчатого канала, вот эти шаги:

1. Создать канал с помощью pipe(). Это должно быть сделано сначала, чтобы два порожденных процесса могли унаследовать дескрипторы открытых файлов.

2. Создать то, что мы называем «левым потомком». Это процесс, стандартный вывод которого идет в канал. В данном процессе сделать следующее:

 a. Использовать 'close(pipefd[0])', поскольку читаемый конец канала в левом потомке не нужен.

 b. Использовать 'close(1)', чтобы закрыть первоначальный стандартный вывод.

 c. Использовать 'dup(pipefd[1])' для копирования записываемого конца канала в дескриптор файла 1.

 d. Использовать 'close(pipefd[1])', поскольку нам не нужны две копии открытого дескриптора.

 e. Выполнить exec для запускаемой программы.

3. Создать то, что мы называем «правым потомком». Это процесс, стандартный ввод которого поступает из канала. Шаги для этого потомка являются зеркальным отражением шагов для левого потомка:

 a. Использовать 'close(pipefd[1])', поскольку записываемый конец канала в правом потомке не нужен.

 b. Использовать 'close(0)', чтобы закрыть первоначальный стандартный ввод.

 c. Использовать 'dup(pipefd[0])' для копирования читаемого конца канала в дескриптор файла 0.

 d. Использовать 'close(pipefd[0])', поскольку нам не нужны две копии открытого дескриптора.

 e. Выполнить exec для запускаемой программы.

4. В родителе закрыть оба конца канала — 'close(pipefd[0]); close(pipefd[1])'.

5. Наконец, использовать в родителе wait() для ожидания завершения обоих порожденных процессов.

Обратите внимание, как важно закрыть неиспользуемые копии дескрипторов файлов каналов. Как мы отмечали ранее, файл не закрывается до тех пор, пока не будет закрыт последний открытый для него дескриптор. Это верно, даже если дескрипторы файлов разделяют несколько процессов. Закрытие не использующихся дескрипторов файлов имеет значение, поскольку процесс, читающий из канала, не получит указания конца файла, пока все копии записываемого конца не будут закрыты.

В нашем случае после порождения двух потомков имеются три процесса, у каждого из которых есть копии двух дескрипторов файлов каналов: родительский и два порожденных. Родительский процесс закрывает оба конца, поскольку ему не нужен канал. Левый потомок записывает в канал, поэтому ему нужно закрыть читаемый конец. Правый потомок читает из канала, поэтому ему нужно закрыть записываемый конец. Это оставляет открытым ровно по одной копии дескриптора файла.

Когда левый потомок завершает работу, он заканчивается. Система после этого закрывает все его дескрипторы файлов. Когда это случается, правый потомок получает в конечном счете уведомление конца файла и тоже может завершить работу и выйти.

Следующая программа, ch09-pipeline.c, создает эквивалент следующего конвейера оболочки:

$ echo hi there | sed s/hi/hello/g

hello there

Вот программа:

1  /* ch09-pipeline.c --- ответвляет два процесса в их собственный конвейер.

2     Для краткости проверка ошибок сведена к минимуму. */

3

4  #include <stdio.h>

5  #include <errno.h>

6  #include <sys/types.h>

7  #include <sys/wait.h>

8  #include <unistd.h>

9

10 int pipefd[2];

11

12 extern void left_child(void), right_child(void);

13

14 /* main --- порождение процессов и ожидание их завершения */

15

16 int main(int argc, char **argv)

17 {

18  pid_t left_pid, right_pid;

19  pid_t ret;

20  int status;

21

22  if (pipe(pipefd) < 0) { /* создать канал в самом начале */

23   perror("pipe");

24   exit(1);

25  }

26

27  if ((left_pid = fork()) < 0) { /* порождение левого потомка */

28   perror("fork");

29   exit(1);

30  } else if (left_pid == 0)

31  left_child();

32

33  if ((right_pid = fork()) < 0) { /* порождение правого потомка */

34   perror("fork");

35   exit(1);

36  } else if (right_pid == 0)

37  right_child();

38

39  close(pipefd[0])); /* закрыть родительские копии канала */

40  close(pipefd[1]);

41

42  while ((ret = wait(&status)) > 0) { /* wait for children */

43   if (ret == left_pid)

44    printf("left child terminated, status: %x\n", status);

45   else if (ret == right_pid)

46    printf("right child terminated, status: %x\n", status);

47   else

48    printf("yow! unknown child %d terminated, status %x\n",

49     ret, status);

50  }

51

52  return 0;

53 }

Строки 22–25 создают канал. Это должно быть сделано в самом начале.

Строки 27–31 создают левого потомка, а строки 33–37 создают правого потомка. В обоих случаях родитель продолжает линейное исполнение ветви main() до тех пор, пока порожденный процесс не вызовет соответствующую функцию для манипулирования дескрипторами файла и осуществления exec.

Строки 39–40 закрывают родительскую копию канала.

Строки 42–50 в цикле ожидают потомков, пока wait() не вернет ошибку.

55 /* left_child --- осуществляет работу левого потомка */

56

57 void left_child(void)

58 {

59  static char *left_argv[] = { "echo", "hi", "there", NULL };

60

61  close(pipefd[0]);

62  close(1);

63  dup(pipefd[1]);

64  close(pipefd[1]);

65

66  execvp("echo", left_argv);

67  _exit(errno == ENOENT ? 127 : 126);

68 }

69

70 /* right_child --- осуществляет работу правого потомка */

71

72 void right_child(void)

73 {

74  static char *right_argv[] = { "sed", "s/hi/hello/g", NULL };

75

76  close(pipefd[1]);

77  close(0);

78  dup(pipefd[0]);

79  close(pipefd[0]));

80

81  execvp("sed", right_argv);

82  _exit(errno == ENOENT ? 127 : 126);

83 }

Строки 57–68 являются кодом для левого потомка. Процедура следует приведенным выше шагам, закрывая ненужный конец канала, закрывая первоначальный стандартный вывод, помещая с помощью dup() записываемый конец канала на номер 1 и закрывая затем первоначальный записываемый конец. В этот момент строка 66 вызывает execvp(), и если она завершается неудачей, строка 67 вызывает _exit(). (Помните, что строка 67 никогда не выполняется, если execvp() завершается удачно.)

Строки 72–83 делают подобные же шаги для правого потомка. Вот что происходит при запуске:

$ ch09-pipeline /* Запуск программы */

left child terminated, status: 0 /* Левый потомок завершается до вывода (!) */

hello there /* Вывод от правого потомка */

right child terminated, status: 0

$ ch09-pipeline /* Повторный запуск программы */

hello there /* Вывод от правого потомка и ... */

right child terminated, status: 0 /* Правый потомок завершается до левого */

left child terminated, status: 0

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

Весь процесс показан на рис. 9.5.



Рис. 9.5. Создание конвейера родителем

На рис. 9.5 (а) изображена ситуация после создания родителем канала (строки 22–25) и двух порожденных процессов (строки 27–37).

На рис. 9.5 (b) показана ситуация после закрытия родителем канала (строки 39–40) и начала ожидания порожденных процессов (строки 42–50). Каждый порожденный процесс поместил канал на место стандартного вывода (левый потомок, строки 61–63) и стандартного ввода (строки 76–78).

Наконец, рис. 9.5 (с) изображает ситуацию после закрытия потомками первоначального канала (строки 64 и 79) и вызова execvp() (строки 66 и 81).

9.4.2. Создание нелинейных конвейеров: /dev/fd/XX

Многие современные системы Unix, включая GNU/Linux, поддерживают в каталоге /dev/fd[98] специальные файлы. Эти файлы представляют дескрипторы открытых файлов с именами /dev/fd/0, /dev/fd/1 и т.д. Передача такого имени функции open() возвращает новый дескриптор файла, что в сущности является тем же самым, что и вызов dup() для данного номера дескриптора.

Эти специальные файлы находят свое применение на уровне оболочки: Bash, ksh88 (некоторые версии) и ksh93 предоставляют возможность замещения процесса (process substitution), что позволяет создавать нелинейные конвейеры. На уровне оболочки для входного конвейера используется запись '<(...)', а для выходного конвейера запись '>(...)'. Например, предположим, вам нужно применить команду diff к выводу двух команд. Обычно вам пришлось бы использовать временные файлы:

command1 > /tmp/out.$$.1

command2 > /tmp/out.$$.2

diff /tmp/out.$$.1 /tmp/out.$$.2

rm /tmp/out.$$.1 /tmp/out.$$.2

С замещением процессов это выглядит следующим образом:

diff <(command1) <(command2)

Не надо никаких беспорядочных файлов для временного запоминания и удаления. Например, следующая команда показывает, что наш домашний каталог является ссылкой на другой каталог:

$ diff <(pwd) <(/bin/pwd)

1c1

< /home/arnold/work/prenhall/progex

---

> /d/home/arnold/work/prenhall/progex

Незамысловатая команда pwd является встроенной в оболочку: она выводит текущий логический путь, который управляется оболочкой с помощью команды cd. Программа /bin/pwd осуществляет обход физической файловой системы для вывода имени пути.

Как выглядит замещение процессов? Оболочка создает вспомогательные команды[99] ('pwd' и '/bin/pwd'). Выход каждой из них подсоединяется к каналу, причем читаемый конец открыт в дескрипторе нового файла для главного процесса ('diff'). Затем оболочка передает главному процессу имена файлов в /dev/fd в качестве аргументов командной строки. Мы можем увидеть это, включив в оболочке трассировку исполнения.

$ set -х /* Включить трассировку исполнения */

$ diff <(pwd) <(/bin/pwd) /* Запустить команду */

+ diff /dev/fd/63 /dev/fd/62 /* Трассировка оболочки: главная,

 программа, обратите внимание на аргументы */

++ pwd /* Трассировка оболочки: вспомогательные программы */

++ /bin/pwd

1c1 /* Вывод diff */

< /home/arnold/work/prenhall/progex

---

> /d/home/arnold/work/prenhall/progex

Это показано на рис. 9.6.

Рис. 9.6. Замещение процесса

Если на вашей системе есть /dev/fd, вы также можете использовать преимущества этой возможности. Однако, будьте осторожны и задокументируйте то, что вы делаете. Манипуляции с дескриптором файла на уровне С значительно менее прозрачны, чем соответствующие записи оболочки!

9.4.3. Управление атрибутами файла: fcntl()

Системный вызов fcntl() («управление файлом») предоставляет контроль над различными атрибутами либо самого дескриптора файла, либо лежащего в его основе открытого файла. Справочная страница GNU/Linux fcntl(2) описывает это таким способом:

#include <unistd.h> /* POSIX */

#include <fcntl.h>


int fcntl (int fd, int cmd);

int fcntl(int fd, int cmd, long arg);

int fcntl(int fd, int cmd, struct flock *lock);

Другими словами, функция принимает по крайней мере два аргумента; в зависимости от второго аргумента, она может принимать и третий аргумент.

Последняя форма, в которой третий аргумент является указателем на struct flock, предназначена для блокировки файла. Блокировка файлов сама по себе представляет большую тему; мы отложим обсуждение до раздела 14.2 «Блокировка файлов».

9.4.3.1. Флаг close-on-exec

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

Организационно такое поведение может представлять проблему. Часть вашей программы, порождающая новый процесс, не должна особенно нуждаться в других частях программы, манипулирующей открытыми файлами. И цикл наподобие следующего неприятный, поскольку может не быть открытых файлов:

int j;

for (j = getdtablesize(); j >= 3; j--) /* закрыть все, кроме 0, 1, 2 */

 (void)close(j);

Решением является флаг close-on-exec (закрытие при исполнении exec). Он является атрибутом самого дескриптора файла, а не лежащего в его основе открытого файла. Когда этот флаг установлен, система автоматически закрывает файл, когда процесс осуществляет exec. Установив этот флаг сразу после открытия файла, вам не нужно беспокоиться о том, что какой-нибудь порожденный процесс случайно его унаследует. (Оболочка автоматически устанавливает этот флаг для всех дескрипторов файлов, которые она открывает, начиная с номера 3 и выше.)

Аргумент cmd имеет два значения, относящиеся к флагу close-on-exec:

F_GETFD

Получает флаги дескриптора файла. Возвращаемое значение является значением всех установленных флагов дескриптора или -1 при ошибке.

F_SETFD

Устанавливает флаги дескриптора файла в содержащееся в arg (третий аргумент) значение. Возвращаемое значение равно 0 при успехе или -1 при ошибке.

В настоящий момент определен лишь один «флаг дескриптора файла»: FD_CLOEXEC. Эта именованная константа является нововведением POSIX[100], а большая часть кода использует просто 1 или 0:

if (fcntl(fd, F_SETFD, 1) < 0) ...

 /* установить close-on-exec, обработать ошибки */

if (fcntl(fd, F_GETFD) == 1) ...

 /* бит close-on-exec уже установлен */

Однако, определение POSIX допускает дальнейшее расширение, поэтому правильный способ написания такого кода больше соответствует этим строкам:

int fd;

long fd_flags;

if ((fd_flags = fcntl(fd, F_GETFD)) < 0) /* Получить флаги */

 /* обработать ошибки */

fd_flags |= FD_CLOEXEC; /* Add close-on-exec flag */

if (fcntl(fd, F_SETFD, fd_flags) < 0) /* Установить флаги */

 /* обработать ошибки */

ЗАМЕЧАНИЕ. Флаг close-on-exec является собственностью дескриптора, а не лежащего в его основе файла. Поэтому новый дескриптор, возвращенный функциями dup() или dup2() (или fcntl() с F_DUPD, которую мы намереваемся посмотреть), не наследует установки флага close-on-exec первоначального дескриптора. Если вам нужно установить его также и для нового дескриптора файла, вы должны не забыть сделать это сами. Такое поведение имеет смысл: если вы просто вызвали dup(), копируя один конец канала в 0 или 1, вы не захотите, чтобы система закрыла его вместо вас, как только процесс осуществит exec!

История борьбы close-on-exec от gawk
В языке awk операторы ввода/вывода используют обозначение перенаправления, сходное с обозначением для оболочки. Это включает односторонние каналы к и от подпроцесса:

print "something brilliant" > "/some/file" /* Вывод в файл */

getline my_record < "/some/other/file" /* Ввод из файла */

print "more words of wisdom" | "a_reader process" /* Вывод в подпроцесс */

"a_write_process" | getline some_input /* Ввод из подпроцесса */

У интерпретатора awk есть дескрипторы открытых файлов для всех перенаправлений файлов, а для обозначений каналов, создающих подпроцессы, интерпретатор awk создает канал, а затем осуществляет fork и exec оболочки для запуска команды, приведенной в строке.

Теперь на современных системах часть стартового кода библиотеки С времени исполнения (который запускается до вызова main()) нуждается для управления использованием разделяемых библиотек во временно открытых файлах. Это означает, что для новой программы после исполнения exec должны быть по крайней мере один или два неиспользуемых дескриптора файла, иначе программа просто не будет работать

Однажды один пользователь сообщил, что когда в программе было максимальное количество открытых файлов, ни один процесс, для которого она пыталась использовать для конвейера fork и exec, не мог успешно начаться!

Вы, возможно, можете догадаться, что произошло. Порожденная оболочка унаследовала дескрипторы открытых файлов, которые gawk сама использовала для своих перенаправлений. Мы модифицировали gawk так, чтобы установить флаг close-on-exec для всех перенаправлений файлов и каналов, что и решило проблему.

9.4.3.2. Дублирование дескриптора файла

Когда аргумент cmd функции fcntl() равен F_DUPFD, ее поведение похоже, но не идентично поведению dup2(). В этом случае arg является дескриптором файла, представляющим наименьшее приемлемое значение для нового дескриптора файла:

int new_fd = fcntl(old_fd, F_DUPFD, 7);

 /* Возвращаемое значение между 7 и максимумом или неудача */

int new_fd = dup2(old_fd, 7);

 /* Возвращаемое значение 7 или неудача */

Вы можете имитировать поведение dup(), которая возвращает наименьший свободный дескриптор файла, использовав 'fcntl(old_fd, F_DUPED, 0)'.

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

Использовать ли в собственном коде fcntl() с F_DUPED или dup() или dup2(), в значительной степени является делом вкуса. Все три функции API являются частью POSIX и широко поддерживаются. У нас легкое пристрастие к dup() и dup2(), поскольку они более специфичны в своих действиях, поэтому являются самодокументирующимися. Но поскольку все они довольно просты, эта аргументация может вас не убедить.

9.4.3.3. Работа с флагами статуса файла и режимами доступа

В разделе 4.6.3 «Возвращаясь к open()» мы предоставили полный список флагов O_xx, которые принимает open(). POSIX разбивает их по функциям, классифицируя в соответствии с табл. 9.4.


Таблица 9.4. Флаги O_xx для open(), creat() и fcntl()

Категория Функции Флаги
Доступ к файлу open(), fcntl() O_RDONLY, O_RDWR, O_WRONLY
Создание файла open() O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC
Статус файла open(), fcntl() O_APPEND, O_DSYNC, O_NONBLOCK, O_RSYNC, O_SYNC
Помимо первоначальной установки различных флагов с помощью open(), вы можете использовать fcntl() для получения текущих установок, а также их изменения. Это осуществляется с помощью значений cmd F_GETFL и F_SETFL соответственно. Например, вы можете использовать эти команды для изменения установки неблокирующего флага, O_NONBLOCK, подобным образом:

int fd_flags;

if ((fd_flags = fcntl(fd, F_GETFL)) < 0)

 /* обработать ошибку */

if ((fd_flags & O_NONBLOCK) != 0) { /* Установлен неблокирующий флаг */

 fd_flags &= ~O_NONBLOCK; /* Сбросить его */

 if (fcntl(fd, F_SETFL, fd_flags) != 0) /* Дать ядру новое значение */

  /* обработать ошибку */

}

Помимо самих режимов именованная константа O_ACCMODE является маской, которую вы можете использовать для выделения из возвращаемого значения режимов прав доступа.

fd_flags = fcntl(fd, F_GETFL);

switch (fd_flags & O_ACCESS) {

case O_RDONLY:

 /* ...действия только для чтения... */

 break;

case O_WRONLY:

 /* ...действия только для записи... */

 break;

case O_RDWR:

 /* ...действия для чтения и записи... */

 break;

}

POSIX требует, чтобы O_RDONLY, O_RDWR и O_WRONLY были побитово различными, таким образом, гарантируется, что код, подобный только что показанному, будет работать и является простым способом определения того, как был открыт произвольный дескриптор файла.

Используя F_SETFL вы можете также изменить эти режимы, хотя по-прежнему применяется проверка прав доступа. Согласно справочной странице GNU/Linux fcnlt(2) флаг O_APPEND не может быть сброшен, если он использовался при открытии файла.

9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO

Ранее для описания способа работы каналов мы использовали сравнение с двумя людьми, моющими и вытирающими тарелки с использованием сушилки; когда сушилка заполняется, останавливается моющий, а когда она пустеет, останавливается вытирающий. Это блокирующее поведение: производитель или потребитель блокируются в вызове write() или read(), ожидая либо освобождения канала, либо появления в нем данных.

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

На языке Unix/POSIX эта концепция обозначается термином неблокирующий ввод/вывод, т.е. запрошенный ввод/вывод либо завершается, либо возвращает значение ошибки, указывающее на отсутствие данных (для читающего) или отсутствие места (для записывающего). Неблокирующий ввод/вывод применяется к каналам и FIFO, а не к обычным файлам на диске. Он может применяться также и к определенным устройствам, таким как терминалы, и к сетевым соединениям, обе эти темы выходят за рамки данной книги.

С функцией open() может использоваться флаг O_NONBLOCK для указания неблокирующего ввода/вывода, он может быть установлен и сброшен с помощью fcntl(). Для open() и read() неблокирующий ввод/вывод прост.

Открытие FIFO с установленным или сброшенным O_NONBLOCK демонстрирует следующее поведение:

open("/fifо/file", O_RDONLY, mode)

Блокируется до открытия FIFO для записи.

open("/fifo/file", O_RDONLY | O_NONBLOCK, mode)

Открывает файл, возвращаясь немедленно.

open("/fifo/file", O_WRONLY, mode)

Блокирует до открытия FIFO для чтения.

open("/fifo/file", O_WRONLY | O_NONBLOCK, mode)

Если FIFO был открыт для чтения, открывает FIFO и немедленно возвращается. В противном случае возвращает ошибку (возвращаемое значение -1 и errno установлен в ENXIO).

Как описано для обычных каналов, вызов read() для FIFO, который больше не открыт для чтения, возвращает конец файла (возвращаемое значение 0). Флаг O_NONBLOCK в данном случае неуместен. Для пустого канала или FIFO (все еще открытых для записи, но не содержащих данных) все становится интереснее:

read(fd, buf, count) и сброшенный O_NONBLOCK

Функция read() блокируется до тех пор, пока в канал или FIFO не поступят данные.

read(fd, buf, count) и установленный O_NONBLOCK

Функция read() немедленно возвращает -1 с установленным в errno EAGAIN.

В заключение, поведение write() более сложно. Для обсуждения этого нам нужно сначала представить концепцию атомарной записи. Атомарная запись — это такая запись, при которой все данные записываются целиком, не чередуясь с данными от других записей. POSIX определяет в <unistd.h> константу PIPE_BUF. Запись в канал или FIFO данных размером менее или равным PIPE_BUF байтов либо успешно завершается, либо блокируется в соответствии с подробностями, которые мы скоро приведем. Минимальным значением для PIPE_BUF является _POSIX_PIPE_BUF, что равняется 512. Само значение PIPE_BUF может быть больше; современные системы GLIBC определяют ее размер в 4096, но в любом случае следует использовать эту именованную константу и не ожидать, что PIPE_BUF будет иметь то же значение на разных системах.

Во всех случаях для каналов и FIFO write() добавляет данные в конец канала. Это происходит от того факта, что у каналов нет файловых смещений: в них нельзя осуществлять поиск.

Также во всех случаях, как упоминалось, записи размером вплоть до PIPE_BUF являются атомарными: данные не перемежаются с данными от других записей. Данные записи размером более PIPE_BUF байтов могут перемежаться с данными других записей в произвольных границах. Это последнее означает, что вы не можете ожидать, что каждая порция размером PIPE_BUF большого набора данных будет записана атомарно. Установка O_NONBLOCK не влияет на это правило.

Как и в случае с read(), когда O_NONBLOCK не установлен, write() блокируется до тех пор, пока все данные не будут записаны.

Наиболее все усложняется, когда установлен O_NONBLOCK. Канал или FIFO ведут себя следующим образом:

размер ≥ nbytes размер < abytes
nbytes ≤ PIPE_BUF write() успешна write() возвращает (-1)/EAGAIN
размер > 0 размер = 0
nbytes > PIPE_BUF write() записывает, что может write() возвращает (-1)/EAGAIN
Для файлов, не являющихся каналами и FIFO и к которым может быть применен O_NONBLOCK, поведение следующее:

размер > 0 write() записывает, что может

размер = 0 write() возвращает -1/EAGAIN

Хотя есть ряд сбивающих с толку изменений поведения в зависимости от того, канал это или не канал, установлен O_NONBLOCK или сброшен, есть в канале место для записи или нет, а также в зависимости от размера предполагаемой записи, эти правила предназначены для упрощения программирования:

• Всегда можно отличить конец файла: read() возвращает 0 байтов.

• Если нет доступных для чтения данных, read() либо завершается успешно, либо возвращает указание «нет данных для чтения»: EAGAIN, что означает «попытайтесь снова позже».

• Если для записи нет места, write() либо блокируется до успешного завершения (O_NONBLOCK сброшен), либо завершается неудачей с ошибкой «в данный момент нет места для записи»: EAGAIN.

• Когда место есть, будет записано столько данных, сколько возможно, так что в конечном счете все данные будут переписаны.

Подводя итог, если вы собираетесь использовать неблокирующий ввод/вывод, любой код, который использует write(), должен быть способен обработать укороченную запись, когда успешно записан меньший объем данных, чем было затребовано. Устойчивый код в любом случае должен быть написан таким способом: даже в случае обычного файла диск может оказаться заполненным и write() сможет записать лишь часть данных.

Более того, вы должны быть готовы обработать EAGAIN, понимая, что в этом случае неудача write() не обязательно означает фатальную ошибку. То же верно для кода, использующего для чтения неблокирующий ввод/вывод: признайте, что и здесь EAGAIN не является фатальным. (Однако, может стоит подсчитывать число таких отказов, оставив попытки, когда их слишком много.)

Неблокирующий ввод/вывод действительно усложняет вашу жизнь, в этом нет никакого сомнения. Но для многих приложений он является необходимостью, позволяющей выполнить задание. Снова рассмотрите спулер печати. Демон спулера не может позволить себе находиться в блокирующем read() для файла FIFO, которому представлены входящие задания. Он должен иметь также возможность отслеживать запущенные задания и, возможно, периодически проверять состояние печатающих устройств (например, убедиться, что не заело бумагу).

9.4.3.5. Сводка fcntl()

Сводка для системного вызова fcntl() приведена в табл. 9.5.


Таблица 9.5. Сводка fcntl()

Значение cmd Значение arg Возвращает
F_DUPFD Наименьший новый дескриптор Дублирует аргумент fd
F_GETFD Получает флаги дескриптора файла (close-on-exec)
F_SETFD Новое значение флага Устанавливает флаги дескриптора файла (close-on-exec)
F_GETFL Получает флаги основного файла
F_SETFL Новое значение флага Устанавливает флаги основного файла
Флаги создания, статуса и прав доступа файла копируются, когда дескриптор файла дублируется. Флаг close-on-exec не копируется.

9.5. Пример: двусторонние каналы в gawk

Двусторонний канал соединяет два процесса двунаправленным образом. Обычно, по крайней мере для одного из процессов, на канал с другим процессом настраиваются как стандартный ввод, так и стандартный вывод. Оболочка Корна (ksh) ввела двусторонние каналы на уровне языка, обозначив термином сопроцесса (coprocess):

команды и аргументы движка базы данных |& /* Запустить сопроцесс в фоновом режиме */

print -p "команда базы данных" /* Записать в сопроцесс */

read -p db_response /* Прочесть из сопроцесса */

Здесь движок базы данных представляет любую серверную программу, которая может управляться интерфейсной частью, в данном случае, сценарием ksh. У движка базы данных стандартный ввод и стандартный вывод подсоединены к оболочке посредством двух отдельных односторонних каналов.[102] Это показано на рис. 9.7.

Рис. 9.7. Сопроцессы оболочки Корна

В обычном awk каналы к или от подпроцесса являются односторонними: нет способа послать данные в программу и прочесть посланные от нее в ответ данные — нужно использовать временный файл. GNU awk (gawk) заимствует обозначение '|&' от ksh для расширения языка awk:

print "команда" |& "движок базы данных" /* Запустить сопроцесс, записать в него */

"движок базы данных" |& getline db_response /* Прочесть из сопроцесса */

gawk использует запись '|&' также для сокетов TCP/IP и порталов BSD, которые не рассматриваются в данной книге. Следующий код из io.c в дистрибутиве gawk 3.1.3 является частью функции two_way_open(), которая устанавливает простой сопроцесс: она создает два канала, порождает новый процесс и осуществляет все манипуляции с дескриптором файла. Мы опустили ряд не относящихся к делу частей кода (эта функция занимает больше места, чем следовало бы):

1561 static int

1562 two_way_open(const char *str, struct redirect *rp)

1563 {

      ...


1827 /* случай 3: двусторонний канал с порожденным процессом */

1828 {

1829  int ptoc[2], сtop[2];

1830  int pid;

1831  int save_errno;

1835

1836  if (pipe(ptoc) < 0)

1837   return FALSE; /* установлен errno, диагностика от вызывающего */

1838

1839  if (pipe(ctop) < 0) {

1840   save_errno = errno;

1841   close(ptoc[0]);

1842   close(ptoc[1]);

1843   errno = save_errno;

1844   return FALSE;

1845  }

Первым шагом является создание двух каналов, ptoc является каналом «от родителя к потомку», а ctop — «от потомка к родителю». Во время чтения держите в уме, что индекс 0 является читаемым концом, а 1 — записываемым.

Строки 1836–1837 создают первый канал, ptoc. Строки 1839–1845 создают второй канал, закрывая при неудачном создании и первый. Это важно. Небрежность в закрытии открытых, но не используемых каналов ведет к утечкам дескрипторов файлов. Как и память, дескрипторы файлов являются конечным ресурсом, и когда они иссякают, то теряются.[103] То же верно и для открытых файлов: убедитесь, что ваш обрабатывающий ошибки код всегда закрывает все открытые файлы и каналы, которые не нужны, когда происходит ошибка.

save_errno сохраняет значения errno, установленные pipe(), на тот редкий случай, когда close() может завершиться неудачей (строка 1840). Затем errno восстанавливается в строке 1843.

1906 if ((pid = fork()) < 0) {

1907  save_errno = errno;

1908  close(ptoc[0]); close(ptoc[1]);

1909  close(ctop[0]); close(ctop[1]);

1910  errno = save_errno;

1911  return FALSE;

1912 }

Строки 1906–1912 порождают процесс, на этот раз закрывая оба канала, если fork() потерпит неудачу. Здесь также первоначальное значение errno сохраняется и восстанавливается для последующего использования при диагностике.

1914 if (pid == 0) { /* порожденный процесс */

1915  if (close(1) == -1)

1916   fatal(_("close of stdout in child failed (%s)"),

1917    strerror(errno));

1918  if (dup(ctop[1]) != 1)

1919   fatal(_{"moving pipe to stdout in child failed (dup: %s)"), strerror(errno));

1920  if (close(0) == -1)

1921   fatal(_("close of stdin in child failed (%s)"),

1922    strerror(errno));

1923  if (dup(ptoc[0]) != 0)

1924   fatal(_("moving pipe to stdin in child failed (dup: %s)"), strerror(errno));

1925  if (close(ptoc[0]) == -1 || close(ptoc[1]) == -1

1926   || close(ctop[0]) == -1 || close(ctop[1]) == -1)

1927   fatal(_("close of pipe failed (%s)"), strerror(errno));

1928  /* stderr HE дублируется в stdout потомка */

1929  execl("/bin/sh", "sh", "-c", str, NULL);

1930  _exit(errno == ENOENT ? 127 : 126);

1931 }

Строки 1914–1931 обрабатывают код потомка, с соответствующей проверкой ошибок и сообщениями на каждом шагу. Строка 1915 закрывает стандартный вывод. Строка 1918 копирует записываемый конец канала от потомка к родителю на 1. Строка 1920 закрывает стандартный ввод, а строка 1923 копирует читаемый конец канала от родителя к потомку на 0. Если это все работает, стандартные ввод и вывод теперь на месте и подключены к родителю.

Строки 1925–1926 закрывают все четыре первоначальные дескрипторы файлов каналов, поскольку они больше не нужны. Строка 1928 напоминает нам, что стандартная ошибка остается на месте. Это лучшее решение, поскольку пользователь увидит ошибки от сопроцесса. Программа awk, которая должна перехватить стандартную ошибку, может использовать в команде обозначение '2>&1' для перенаправления стандартной ошибки сопроцесса или записи в отдельный файл.

Наконец, строки 1929–1930 пытаются запустить для оболочки execl() и соответственно выходят, если это не удается.

1934 /* родитель */

1935 rp->pid = pid;

1936 rp->iop = iop_alloc(ctop[0], str, NULL);

1937 if (rp->iop == NULL) {

1938  (void)close(ctop[0]);

1939  (void)close(ctop[1]);

1940  (void)close(ptoc[0]);

1941  (void)close(ptoc[1]);

1942  (void)kill(pid, SIGKILL); /* overkill? (pardon pun) */

1943

1944  return FALSE;

1945 }

Первым шагом родителя является настройка входного конца от сопроцесса. Указатель rp указывает на struct redirect, которая содержит поле для сохранения PID порожденного процесса, FILE* для вывода и указатель IOBUF* с именем iop. IOBUF является внутренней структурой данных gawk для осуществления ввода. Она, в свою очередь, хранит копию нижележащего дескриптора файла.

Строка 1935 сохраняет значение ID процесса. Строка 1936 выделяет память для новой IOBUF для данных дескриптора файла и командной строки. Третий аргумент здесь равен NULL: он позволяет при необходимости использовать предварительно выделенный IOBUF.

Если выделение памяти потерпело неудачу, строки 1937–1942 производят очистку, закрывая каналы и посылая сигнал «kill» порожденным процессам, чтобы заставить их завершить работу. (Функция kill() описана в разделе 10.6.7 «Отправка сигналов kill() и killpg()».)

1946 rp->fp = fdopen(ptoc[1], "w");

1947 if (rp->fp == NULL) {

1948  iop_close(rp->iop);

1949  rp->iop = NULL;

1950  (void)close(ctop[0]);

1951  (void)close(ctop[1]);

1952  (void)close(ptoc[0]);

1953  (void)close(ptoc[1]);

1954  (void)kill(pid, SIGKILL); /* избыточно? (пардон, каламбур)[104] */

1955

1956  return FALSE;

1957 }

Строки 1946–1957 аналогичны. Они устанавливают вывод родителя на потомка, сохраняя дескриптор файла для записывающего конца канала от родителя к потомку в FILE*, используя функцию fdopen(). Если это завершается неудачей, строки 1947–1957 предпринимают те же действия, что и ранее: закрывают все дескрипторы каналов и посылают сигнал порожденным процессам.

С этого момента записываемый конец канала от родителя к потомку и читаемый конец канала от потомка к родителю хранятся в более крупных структурах: FILE* и IOBUF соответственно. Они автоматически закрываются обычными процедурами, которые закрывают эти структуры. Однако, остаются две задачи:

1960   os_close_on_exec(ctop[0], str, "pipe", "from");

1961   os_close_on_exec(ptoc[1], str, "pipe", "from");

1962

1963   (void)close(ptoc[0]);

1964   (void)close(ctop[1]);

1966

1967   return TRUE;

1968  }

      ...

1977 }

Строки 1960–1961 устанавливают флаг close-on-exec для двух дескрипторов, которые остались открытыми. os_close_on_exec() является простой функцией-оболочкой, которая выполняет эту работу на Unix- и POSIX-совместимых системах, но ничего не делает на системах, в которых нет флага close-on-exec. Это скрывает проблемупереносимости в одном месте и позволяет избежать в коде множества запутывающих #ifdef здесь и в других местах io.c.

Наконец, строки 1963–1964 закрывают концы каналов, которые не нужны родителю, а строка 1967 возвращает TRUE для обозначения успеха.

9.6. Рекомендуемая литература

Управление заданиями сложно, включает группы процессов, сеансы, механизмы ожидания, сигналы и манипулирование группой процессов терминала. По существу, мы решили не вдаваться в детали. Однако, вы можете захотеть взглянуть на следующие книги:

1. Advanced Programming in the UNIX Environment, 2nd edition, by W. Richard Stevens and Stephen Rago. Addison-Wesley, Reading Massachusetts, USA, 2004. ISBN: 0-201-43307-9.

Эта книга и полна, и основательна, охватывая элементарное и продвинутое программирование под Unix. Она превосходно освещает группы процессов, сеансы, управление заданиями и сигналы

2. The Design and Implementation of the 4.4 BSD Operating System, by Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, and John S. Quarterman. Addison-Wesley, Reading, Massachusetts, USA, 1996. ISBN: 0-201-54979-4.

Эта книга дает хороший обзор того же материала, включая обсуждение структур данных ядра, которое можно найти в разделе 4.8 этой книги.

9.7. Резюме

• Новые процессы создаются с помощью fork(). После этого оба процесса исполняют один и тот же код, причем единственным различием является возвращаемое значение: 0 в порожденном процессе и положительный номер PID в родительском. Порожденный процесс наследует копии почти всех атрибутов родителя, наиболее важными из которых являются, пожалуй, открытые файлы.

• Унаследованные разделяемые дескрипторы файлов делают возможным многое из высокоуровневой семантики Unix и элегантные управляющие структуры оболочки. Это одна из наиболее фундаментальных частей оригинального дизайна Unix. Из-за разделения дескрипторов файл на самом деле не закрывается до тех пор, пока не будет закрыт последний открытый дескриптор файла. Это в особенности касается каналов, но затрагивает также освобождение дисковых блоков для удаленных, но все еще открытых файлов.

• Вызовы getpid() и getppid() возвращают ID текущего и родительского процессов соответственно. Родителем процесса, первоначальный родитель которого завершается, становится специальный процесс init с PID 1. Таким образом, PPID может меняться, и приложения должны быть готовы к этому.

• Системный вызов nice() дает возможность настраивать приоритет вашего процесса. Чем приятнее вы по отношению к другим процессам, тем меньше ваш относительный приоритет, и наоборот. Лишь суперпользователь может иметь больший приоритет по сравнению с другими процессами. На современных системах, особенно однопользовательских, нет действительных причин для изменения знамения относительного приоритета.

• Системный вызов exec() начинает исполнение новой программы в существующем процессе. Шесть различных версий вызова предоставляют гибкость в установке списков аргументов и окружения ценой первоначальной путаницы по поводу того, какую из них лучше всего использовать. Два варианта имитируют механизм поиска оболочки и отступают к использованию оболочки для интерпретации файла в случае, если он не является двоичным исполняемым файлом; эти варианты должны использоваться с предусмотрительностью.

• Значение argv[0] для новой программы обычно происходит от имени исполняемого файла, но это лишь соглашение. Как и в случае с fork(), значительный, но не идентичный набор атрибутов наследуется через exec. Другие атрибуты сбрасываются для использования подходящих значений по умолчанию.

• Функция atexit() регистрирует функции обратного вызова для вызова в порядке LIFO при завершении программы. Функции exit(), _exit() и _Exit() все завершают программу, передавая статус завершения обратно родителю, exit() очищает открытые потоки FILE* и запускает функции, зарегистрированные с помощью atexit(). Две другие функции завершаются немедленно и должны использоваться, лишь когда exec в порожденном процессе завершилась неудачей. Возвращение из main() подобно вызову exit() с данным возвращаемым значением. В C99 и C++ выпадение из main() в конце функции дает тот же результат, что и 'exit(0)', но является плохой практикой.

• wait() и waitpid() являются функциями POSIX для получения статуса завершения порожденного процесса. Различные макросы позволяют определить, завершился ли порожденный процесс нормально, и в таком случае определить статус его завершения, или же порожденный процесс претерпел сигнал завершения, и в этом случае определить совершивший этот проступок сигнал. Со специальными опциями waitpid() предоставляет также сведения о потомках, которые не завершились, но изменили состояние.

• Системы GNU/Linux и большинство Unix-систем поддерживают также функции BSD wait3() и wait4(). GNU/Linux поддерживает также выходящий из употребления union wait. Функции BSD предоставляют struct rusage, давая доступ к сведениям об использовании времени процессора, что может быть удобным. Хотя если waitpid() будет достаточной, то это наиболее переносимый способ выполнения.

• Группы процессов являются частью более крупного механизма управления заданиями, который включает сигналы, сеансы и манипулирование состоянием терминала, getpgrp() возвращает ID группы процессов текущего процесса, a getpgid() возвращает PGID определенного процесса. Сходным образом, setpgrp() устанавливает PGID текущего процесса равным его PID, делая его лидером группы процессов; setpgid() дает возможность родительскому процессу установить PGID порожденного, который еще не выполнил exec.

• Каналы и FIFO предоставляют односторонний коммуникационный канал между двумя процессами. Каналы должны быть установлены общим предком, тогда как FIFO могут использоваться любыми двумя процессами. Каналы создаются с помощью pipe(), а файлы FIFO создаются с помощью mkfifo(). Каналы и FIFO буферируют свои данные, останавливая производителя или потребителя, когда канал заполняется или пустеет.

• dup() и dup2() создают копии дескрипторов открытых файлов. В сочетании с close() они дают возможность поместить дескрипторы файлов на место стандартного ввода и вывода для каналов. Чтобы каналы работали правильно, все копии неиспользуемых концов каналов до исполнения программой назначения exec должны быть закрыты. Для создания нелинейных каналов может быть использован /dev/fd, что демонстрируется возможностью замещения процессов оболочками Bash и Korn.

• fcntl() является функцией для выполнения различных работ. Она управляет атрибутами как самого дескриптора файла, так и лежащего в его основе файла. В данной главе мы видели, что fcntl() используется для следующего:

 • Дублирования дескриптора файла, имитирования dup() и почти имитирования dup2().

 • Получения и установки флага close-on-exec. Флаг close-on-exec является в настоящее время единственным атрибутом дескриптора файла, но он важен. Он не копируется в результате действия dup(), но должен явным образом устанавливаться для дескрипторов файлов, которые не должны оставаться открытыми после выполнения exec. На практике, это должно быть сделано для большинства дескрипторов файла.

 • Получение и установка флагов, управляющих нижележащим файлом. Из них O_NONBLOCK является, пожалуй, наиболее полезным, по крайней мере, для FIFO и каналов. Это определенно самый сложный флаг.

Упражнения

1. Напишите программу, которая выводит как можно больше сведений о текущем процессе: PID, PPID, открытые файлы, текущий каталог, значение относительного приоритета и т.д. Как вы можете сказать, какие файлы открыты? Если несколько дескрипторов файлов ссылаются на один и тот же файл, укажите это. (Опять-таки, как вы можете это узнать?)

2. Как вы думаете, atexit() хранит указатели на функции обратного вызова? Реализуйте atexit(), держа в уме принцип GNU «никаких произвольных ограничений». Набросайте схему (псевдокод) для exit(). Каких сведений (внутренностей библиотеки <stdio.h>) вам не хватает, чтобы написать exit()?

3. Программа xargs предназначена для многократных запусков команды и аргументов, когда аргументов слишком много для непосредственного набора в командной строке. Программа работает, считывая строки из стандартного ввода, рассматривая каждую строку в качестве отдельного аргумента для указанной команды, и упаковывая аргументы до тех пор, пока они остаются в пределах максимально допустимого для системы. Например:

$ grep ARG_MAX /usr/include/*.h /usr/include/*/*.h /* Командная строка */

bash: /bin/grep: Argument list too long /* Сообщение оболочки об ошибке */

$ find /usr/include -name '*.h' | xargs grep ARG_MAX /* find b xargs работают */

/usr/include/sys/param.h:#define NCARGS ARG_MAX

...

Константа ARG_MAX в <limits.h> представляет сочетание общей памяти, используемой средой, и аргументов командной строки. Стандарт POSIX не говорит, включает ли это массивы указателей или просто сами строки.

Напишите простую версию xargs, которая работает указанным способом. Не забудьте об окружении при вычислении размера необходимого пространства. Убедитесь, что тщательно управляете памятью.

4. Компоновка значения status, заполняемого функциями wait() и waitpid(), стандартом POSIX не определяется. Хотя и историческое, это 16-разрядное значение, которое выглядит, как показано на рис. 9.8.

Рис. 9.8. Компоновка значения status функции wait()

 • Ненулевое значение в битах 0–7 указывает на завершение по сигналу.

 • Все единичные биты в поле сигнала указывает, что порожденный процесс остановлен. В этом случае биты 9-15 содержат номер сигнала.

 • Единичное значение бита 8 указывает завершение со снимком процесса.

 • Если биты 0–7 равны нулю, процесс завершился нормально. В этом случае биты 9–15 являются статусом завершения.

Напишите с данными сведениями макросы POSIX WIFEXITED() и др.

5. Помня, что dup2() сначала закрывает запрошенный дескриптор файла, реализуйте dup2(), используя close() и fcntl(). Как вы обработаете случай, когда fcntl() возвращает значение меньше запрошенного?

6. Есть ли на вашей системе каталог /dev/fd? Если есть, как он реализован?

7. Напишите новую версию ch09-pipeline.c, которая порождает лишь один процесс. После порождения родитель должен поменять дескрипторы своих файлов и сам выполнить exec для одной из новых программ.

8. (Трудное) Как вы можете узнать, вызывал ли ваш процесс когда-нибудь chroot()? Напишите программу, которая проверяет это и выводит сообщение с ответом да или нет. Можно ли обмануть вашу программу? Если да, как?

9. Есть ли на вашей системе каталог /proc? Если да, доступ к какой информации о процессе он обеспечивает?

Глава 10 Сигналы

Данная глава освещает все подробности сигналов, важную, но сложную часть GNU/Linux API.

10.1. Введение

Сигнал является указанием, что случилось какое-то событие, например, попытка сослаться на адрес памяти, который не является частью адресного пространства вашей программы, или когда пользователь нажимает CTRL-C для выхода из программы (называется генерированием прерывания).

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

Механизмы обработки сигналов развились с течением времени. Как бывает почти со всеми такими механизмами, стандартизованы и доступны как первоначальные, так и более новые API. Однако, из фундаментальных API обработка сигналов обнаруживает, возможно, самые широкие изменения; имеется множество возможностей обработки, чтобы преуспеть в использовании наиболее подходящего API. В результате, возможно, это самая трудная глава в книге. Мы сделаем всевозможное, чтобы сделать изложение более ясным, но если вы проработаете эту главу более тщательно, чем обычно, это поможет.

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

10.2. Действия сигналов

Каждый сигнал (вскоре мы представим полный список) имеет связанное с ним действие по умолчанию. POSIX обозначает это как диспозицию (disposition) сигнала. Это то действие, которое ядро осуществляет для процесса, когда поступает определенный сигнал. Действие по умолчанию варьирует:

Завершение

Процесс завершается.

Игнорирование

Сигнал игнорируется. Программа никогда не узнает, что что-то случилось.

Снимок образа процесса

Процесс завершается, и ядро создает файл core (в текущем каталоге процесса), содержащий образ работавшей на момент поступления сигнала программы. Снимок процесса может впоследствии использоваться с отладчиком для исследования состояния программы (см. главу 15 «Отладка»).

По умолчанию системы GNU/Linux создают файлы с именем core.pid, где pid является ID завершаемого процесса. (Это можно изменить; см. sysctl(8).) Такое именование позволяет хранить в одном и том же каталоге несколько файлов core, за счет использования большего дискового пространства.[105] Традиционные системы Unix называют файл core, и это ваше дело сохранить какие-нибудь файлы core для последующего изучения, если есть шанс создания других таких же файлов в том же каталоге.

Остановка

Процесс останавливается. Впоследствии он может быть возобновлен. (Если вы использовали управление заданиями оболочки с помощью CTRL-Z, fg и bg, вы понимаете остановку процесса.)

10.3. Стандартные сигналы С: signal() и raise()

Стандарт ISO С определяет первоначальный API управления сигналами V7 и новый API для посылки сигналов. Вы должны использовать их для программ, которым придется работать на не-POSIX системах, или в случаях, когда предоставляемые ISO С API возможности являются достаточными.

10.3.1. Функция signal()

Действие сигнала изменяется с помощью функции signal(). Вы можете изменить действие на «игнорировать сигнал», «восстановить для сигнала действие системы по умолчанию» или «вызвать при появлении сигнала мою функцию с номером сигнала в качестве параметра».

Функция, которую вы предоставляете для распоряжения сигналом, называется обработчиком сигнала (или просто обработчиком), а установка ее в соответствующем месте осуществляет перехват (catch) сигнала.

Получив эти сведения, давайте перейдем к API. В заголовочном файле <signal.h> представлены определения макросов для поддерживаемых сигналов и объявления функций управления сигналами, предоставляемыми стандартом С:

#include <signal.h> /* ISO С */


void (*signal(int signum, void (*func)(int)))(int);

Это объявление для функции signal() почти невозможно прочесть. Поэтому справочная страница GNU/Linux signal(2) определяет ее таким способом:

typedef void (*sighandler_t)(int);


sighandler_t signal(int signum, sighandler_t handler);

Теперь это более вразумительно. Тип sighandler_t является указателем на функцию с возвращаемым типом void, которая принимает один целый аргумент. Это целое является номером поступающего сигнала.

Функция signal() принимает номер сигнала в качестве своего первого параметра, а указатель функции (новый обработчик) в качестве своего второго аргумента. Если последний не является указателем функции, он может быть лишь SIG_DEF, что означает «восстановить действие по умолчанию», либо SIG_IGN, что означает «игнорировать сигнал».

signal() изменяет действие для signum и возвращает предыдущее действие. (Это дает вам возможность восстановить при желании предыдущее действие.) Возвращаемое значение может равняться также SIG_ERR, что указывает на произошедшую ошибку. (Некоторые сигналы невозможно перехватить или игнорировать; предоставление для них обработчика сигнала или неверный signum создают эту ошибку.) В табл. 10.1 перечислены сигналы, доступные под GNU/Linux, их числовые значения, действия по умолчанию для каждого, формальный стандарт или современная операционная система, которые их определяют, и смысл каждого.


Таблица 10.1. Сигналы GNU/Linux

Имя Значение По умолчанию Источник Смысл
SIGHUP 1 Term POSIX Отсоединение
SIGINT 2 Term ISO C Прерывание
SIGQUIT 3 Core POSIX Выход
SIGILL 4 Core ISO C Недействительная инструкция
SIGTRAP 5 Core POSIX Трассировочная ловушка
SIGABRT 6 Core ISO C Прекращение
SIGIOT 6 Core BSD Ловушка IOT
SIGBUS 7 Core BSD Ошибка шины
SIGFPE 8 Core ISO C Исключение с плавающей точкой
SIGKILL 9 Term POSIX Завершение, неблокируемый
SIGUSR1 10 Term POSIX Сигнал 1 пользователя
SIGSEGV 11 Core ISO C Нарушение сегмента
SIGUSR2 12 Term POSIX Сигнал 2 пользователя
SIGPIPE 13 Term POSIX Нарушенный канал
SIGALRM 14 Term POSIX Аварийные часы
SIGTERM 15 Term ISO C Завершение
SIGSTKFLT 16 Term Linux Ошибка стека в процессоре (не используется)
SIGCHLD 17 Ignr POSIX Изменение статуса порожденного процесса
SIGCLD 17 Ignr System V То же, что и SIGCHLD (для совместимости)
SIGCONT 18 POSIX Продолжить при остановке
SIGSTOP 19 Stop POSIX Стоп, неблокируемый
SIGTSTP 20 Stop POSIX Стоп от клавиатуры
SIGTTIN 21 Slop POSIX Фоновое чтение от tty
SIGTTOU 22 Stop POSIX Фоновая запись в tty
SIGURG 23 Ignr BSD Срочный сигнал сокета
SIGXCPU 24 Core BSD Превышение предела процессора
SIGXFSZ 25 Core BSD Превышение предела размера файла
SIGVTALRM 26 Term BSD Виртуальные аварийные часы
SIGPROF 27 Term BSD Профилирующие аварийные часы
SIGWINCH 28 Ignr BSD Изменение размера окна
SIGIO 29 Term BSD Возможен ввод/вывод
SIGPOLL 29 Term System V Опрашиваемое событие, то же, что и SIGIO (для совместимости)
SIGPWR 30 Term System V Повторный запуск из-за сбоя питания
SIGSYS 31 Core POSIX Неверный системный вызов
Обозначения: Core: Завершить процесс и создать снимок образа процесса Ignr: Игнорировать сигнал Stop: Остановить процесс. Term: Завершить процесс.

Более старые версии оболочки Борна (/bin/sh) непосредственно связывали с номерами сигналов ловушки (traps), которые являются обработчиками сигналов на уровне оболочки. Таким образом, всесторонне образованному Unix-программисту нужно было знать не только имена сигналов для использования в коде С, но также и соответствующие номера сигналов! POSIX требует, чтобы команда trap понимала символические имена сигналов (без префикса 'SIG'), поэтому этого больше не требуется. Однако (главным образом для лучшего разбирательства), мы предоставили эти номера в интересах полноты из-за того, что однажды вам может понадобиться иметь дело со сценарием оболочки, созданным до POSIX, или с древним кодом на С, которые непосредственно используют номера сигналов.

ЗАМЕЧАНИЕ. Для некоторых более новых сигналов, от 16 и выше, соответствующие номера сигнала и их имена на различных платформах не обязательно совпадают! Проверьте заголовочные файлы и справочные страницы на своей системе. Табл. 10.1 верна для GNU/Linux

Некоторые системы определяют также и другие сигналы, такие, как SIGEMT, SIGLOST и SIGINFO. Справочная страница GNU/Linux signal(7) предоставляет полный список; если ваша программа должна обработать сигналы, не поддерживаемые GNU/Linux, это можно сделать с помощью #ifdef:

#ifdef SIGLOST

/* ...обработать здесь SIGLOST... */

#endif

За исключением SIGSTKFLT, сигналы, перечисленные в табл. 10.1, широкодоступны и не нуждаются в заключении в #ifdef.

Сигналы SIGKILL и SIGSTOP нельзя перехватить или игнорировать (или блокировать, как описано далее в главе). Они всегда выполняют действие по умолчанию, указанное в табл. 10.1.

Чтобы увидеть список поддерживаемых сигналов, вы можете использовать 'kill -l'. На одной из наших систем GNU/Linux:

$ kill -l

 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL

 5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE

 9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2

13) SIGPIPE     14) SIGALRM     15) SIGTERM     17) SIGCHLD

18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN

22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ

26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO

30) SIGPWR      31) SIGSYS      32) SIGRTMIN    33) SIGRTMIN+1

34) SIGRTMIN+2  35) SIGRTMIN+3  36) SIGRTMIN+4  37) SIGRTMIN+5

38) SIGRTMIN+6  39) SIGRTMIN+7  40) SIGRTMIN+8  41) SIGRTMIN+9

42) SIGRTMIN+10 43) SIGRTMIN+11 44) SIGRTMIN+12 45) SIGRTMIN+13

46) SIGRTMIN+14 47) SIGRTMIN+15 48) SIGRTMAX-15 49) SIGRTMAX-14

50) SIGRTMAX-13 51) SIGRTMAX-12 52) SIGRTMAX-11 53) SIGRTMAX-10

54) SIGRTMAX-9  55) SIGRTMAX-8  56) SIGRTMAX-7  57) SIGRTMAX-6

58) SIGRTMAX-5  59) SIGRTMAX-4  60) SIGRTMAX-3  61) SIGRTMAX-2

62) SIGRTMAX-1  63) SIGRTMAX

Сигналы SIGRTXXX являются сигналами реального времени, сложная тема, которую мы не будем рассматривать.

10.3.2. Программная отправка сигналов: raise()

Помимо внешнего генерирования, сигнал может быть отправлен непосредственно самой программой с использованием стандартной функции С raise():

#include <signal.h> /* ISO С */


int raise(int sig);

Эта функция посылает сигнал sig вызывающему процессу. (Это действие имеет свое применение; вскоре мы увидим пример.)

Поскольку raise() определена стандартом С, для процесса это наиболее переносимый способ отправить себе сигнал. Есть другие способы, которые мы обсудим далее в главе.

10.4. Обработчики сигналов в действии

Множество осложнений и отклонений обнаруживается после установки на место обработчика, после его вызова и впоследствии возвращения.

10.4.1. Традиционные системы

После помещения на место обработчика сигнала ваша программа развивается своим путем. Интересные вещи возникают лишь с появлением сигнала (например, пользователь нажал CTRL-C для прерывания вашей программы, или был сделан вызов raise()).

По получении сигнала ядро останавливает процесс, где бы он ни был. Затем оно имитирует вызов процедуры обработчика сигнала, передавая ему номер сигнала в качестве ее единственного аргумента. Ядро устраивает все таким образом, что нормальный возврат из функции обработчика сигнала (либо посредством return, либо в результате выпадения из конца функции) передает управление в ту точку программы, в которой она находилась в момент появления сигнала.

Что происходит после обработки сигнала, когда тот же самый сигнал появится в следующий раз снова? Остается ли обработчик на том же месте? Или же он сбрасывается, и для сигнала используется действие по умолчанию? Ответ, по историческим причинам, «зависит от». В частности, стандарт С оставляет это на усмотрение реализации.

На практике V7 и традиционные системы System V, такие, как Solaris, устанавливают для сигнала действие по умолчанию.

Давайте рассмотрим простой обработчик сигнала в действии под Solaris. Следующая программа, ch10-catchint.c, перехватывает SIGINT. Обычно вы генерируете этот сигнал, набирая на клавиатуре CTRL-C.

1  /* ch10-catchint.c - перехват SIGINT, по крайней мере, однажды. */

2

3  #include <signal.h>

4  #include <string.h>

5  #include <unistd.h>

6

7  /* handler --- простой обработчик сигнала. */

8

9  void handler(int signum)

10 {

11  char buf[200], *cp;

12  int offset;

13

14  /* Пройти через это испытание , чтобы избежать fprintf(). */

15  strcpy(buf, "handler: caught signal ");

16  cp = buf + strlen(buf); /* cp указывает на завершающий '\0' */

17  if (signum > 100) /* маловероятно */

18   offset = 3;

19  else if (signum > 10)

20   offset = 2;

21  else

22   offset = 1;

23  cp += offset;

24

25  *cp-- = '\0'; /* завершить строку */

26  while (signum >0) { /* work backwards, filling in digits */

27   *cp-- = (signum % 10) + '0';

28   signum /= 10;

29  }

30  strcat(buf, "\n");

31  (void)write(2, buf, strlen(buf));

32 }

33

34 /* main --- установить обработку сигнала и войти в бесконечный цикл */

35

36 int main(void)

37 {

38  (void)signal(SIGINT, handler);

39

40  for(;;)

41   pause(); /* ждать сигнал, см. далее в главе */

42

43  return 0;

44 }

Строки 9–22 определяют функцию обработки сигнала (остроумно названную handler()[106]). Все, что эта функция делает, — выводит номер перехваченного сигнала и возвращается. Для вывода этого сообщения она выполняет множество ручной работы, поскольку fprintf() не является «безопасной» для вызова из обработчика сигнала. (Вскоре это будет описано в разделе 10.4.6 «Дополнительные предостережения».)

Функция main() устанавливает обработчик сигнала (строка 38), а затем входит в бесконечный цикл (строки 40–41). Вот что происходит при запуске:

$ ssh solaris.example.com

 /* Зарегистрироваться на доступной системе Solaris */

Last login: Fri Sep 19 04:33:25 2003 from 4.3.2.1.

Sun Microsystems Inc. SunOS 5.9 Generic May 2002

$ gcc ch10-catchint.c /* Откомпилировать программу */

$ a.out /* Запустить ее */

^C handler: caught signal 2 /* Набрать ^C, вызывается обработчик */

^C /* Попробовать снова, но на этот раз... */

$ /* Программа завершается */

Поскольку V7 и другие традиционные системы восстанавливают действие сигнала по умолчанию, поэтому когда вы хотите снова получить сигнал в будущем, функция обработчика должна немедленно переустановить саму себя:

void handler(int signum) {

 char buf[200], *cp;

 int offset;

 (void)signal(signum, handler); /* переустановить обработчик */

 /* ...оставшаяся часть функции как прежде... */

}

10.4.2. BSD и GNU/Linux

BSD 4.2 изменила способ работы signal().[107] На системах BSD обработчик сигнала после его возвращения остается на месте. Системы GNU/Linux следуют поведению BSD. Вот что происходит под GNU/Linux:

$ ch10-catchint          /* Запустить программу */

handler: caught signal 2 /* Набираем ^C, вызывается обработчик */

handler: caught signal 2 /* И снова... */

handler: caught signal 2 /* И снова! */

handler: caught signal 2 /* Помогите! */

handler: caught signal 2 /* Как нам это остановить?! */

Quit (core dumped)       /* ^\, генерирует SIGQUIT. Bay */

На системе BSD или GNU/Linux обработчик сигнала не должен дополнительно использовать 'signal(signum, handler)' для переустановки обработчика. Однако, лишний вызов не причиняет никакого вреда, поэтому сохраняется статус-кво.

В действительности, POSIX предоставляет функцию bsd_signal(), которая идентична signal() за тем исключением, что она гарантирует, что обработчик сигнала останется установленным:

#include <signal.h> /* XSI, устаревает */


void (*bsd_signal(int sig, void (*func)(int)))(int);

Это устраняет проблемы переносимости. Если вы знаете, что ваша программа будет работать лишь на системах POSIX, вы можете воспользоваться bsd_signal() вместо signal().

Одно предостережение — эта функция также помечена как «устаревающая», что означает возможность отказа от нее в будущем стандарте. На практике, даже если от нее откажутся, поставщики скорее всего долгое время будут ее поддерживать. (Как мы увидим, функция API POSIX sigaction() предоставляет достаточно возможностей для написания рабочей версии, если это вам нужно.)

10.4.3. Игнорирование сигналов

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

Например, рассмотрите программу sort. sort, возможно, создала любое число временных файлов для использования на промежуточных этапах процесса сортировки. По получении SIGINT, sort должна удалить временные файлы и выйти. Вот упрощенная версия обработчика сигнала из GNU Coreutils sort.c:

/* Обработка прерываний и отсоединений. Упрощена для представления */

static void sighandler(int sig) {

 signal(sig, SIG_IGN); /* Отныне этот сигнал игнорировать */

 cleanup();            /* Очистка после себя */

 signal(sig, SIG_DFL); /* Восстановление действия по умолчанию */

 raise(sig);           /* Повторно отправить сигнал */

}

Установка действия SIG_IGN гарантирует, что все последующие появляющиеся сигналы SIGINT не повлияют на продолжающийся процесс очистки. Когда функция cleanup() завершит работу, восстановление действия SIG_DFL позволяет системе сделать снимок образа процесса, если это нужно возникшему сигналу. Вызов raise() восстанавливает сигнал. Затем восстановленный сигнал вызывает действие по умолчанию, которое, скорее всего, завершит программу. (Далее в этой главе мы полностью покажем обработчик сигнала sort.c.)

10.4.4. Системные вызовы, допускающие повторный запуск

Значение EINTR для errno (см. раздел 4.3 «Определение ошибок») указывает, что системный вызов был прерван. Хотя с этим значением ошибки может завершаться большое количество системных вызовов, двумя наиболее значительными являются read() и write(). Рассмотрите следующий код:

void handler(int signal) { /* обработка сигналов */ }


int main(int argc, char **argv) {

 signal(SIGINT, handler);

 ...

 while ((count = read(fd, buf, sizeof buf)) > 0) {

  /* Обработка буфера */

 }

 if (count == 0)

  /* конец файла, очистка и т.п. */

 else if (count == -1)

  /* ошибка */

 ...

}

Предположим, что система успешно прочла (и заполнила) часть буфера, когда возник SIGINT. Системный вызов read() еще не вернулся из ядра в программу, но ядро решает, что оно может доставить сигнал. Вызывается handler(), запускается и возвращается в середину read(). Что возвратит read()?

В былые времена (V7, более ранние системы System V) read() возвратила бы -1 и установила бы errno равным EINTR. Не было способа сообщить, что данные были переданы. В данном случае V7 и System V действуют, как если бы ничего не случилось: не было перемещений данных в и из буфера пользователя, и смещение файла не было изменено. BSD 4.2 изменила это. Были два случая:

Медленные устройства

«Медленное устройство» является в сущности терминалом или почти всяким другим устройством, кроме обычного файла. В этом случае read() могла завершиться с ошибкой EINTR, лишь если не было передано никаких данных, когда появился сигнал. В противном случае системный вызов был бы запущен повторно, и read() возвратилась бы нормально.

Обычные файлы

Системный вызов был бы запущен повторно В этом случае read() вернулась бы нормально; возвращенное значение могло быть либо числом запрошенных байтов, либо числом действительно прочитанных байтов (как в случае чтения вблизи конца файла).

Поведение BSD несомненно полезно; вы всегда можете сказать, сколько данных было прочитано.

Поведение POSIX сходно, но не идентично первоначальному поведению BSD. POSIX указывает, что read()[108] завершается с ошибкой EINTR лишь в случае появления сигнала до начала перемещения данных. Хотя POSIX ничего не говорит о «медленных устройствах», на практике это условие проявляется именно на них.

В противном случае, если сигнал прерывает частично выполненную read(), возвращенное значение является числом уже прочитанных байтов. По этой причине (а также для возможности обработки коротких файлов) всегда следует проверять возвращаемое read() значение и никогда не предполагать, что прочитано все запрошенное количество байтов. (Функция POSIX API sigaction(), описанная позже, позволяет при желании получить поведение повторно вызываемых системных вызовов BSD.)

10.4.4.1. Пример: GNU Coreutils safe_read() и safe_write()

Для обработки случая EINTR в традиционных системах GNU Coreutils использует две функции, safe_read() и safe_write(). Код несколько запутан из-за того, что один и тот же файл за счет включения #include и макросов реализует обе функции. Из файла lib/safe-read.c в дистрибутиве Coreutils:

1  /* Интерфейс read и write для .повторных запусков после прерываний.

2     Copyright (С) 1993, 1994, 1998, 2002 Free Software Foundation, Inc.

   /* ... куча шаблонного материала опущена... */

56

57 #ifdef SAFE_WRITE

58 # include "safe-write.h"

59 # define safe_rw safe_write /* Создание safe_write() */

60 # define rw write /* Использование системного вызова write() */

61 #else

62 # include "safe-read.h"

63 # define safe_rw safe_read /* Создание safe_read() */

64 # define rw read /* Использование системного вызова read() */

65 # undef const

66 # define const /* пусто */

67 #endif

68

69 /* Прочесть (записать) вплоть до COUNT байтов в BUF из(в) дескриптора FD, повторно запуская вызов при

70 прерывании. Вернуть число действительно прочитанных (записанных) байтов, 0 для EOF

71 или в случае ошибки SAFE_READ_ERROR(SAFE_WRITE_ERROR). */

72 size_t

73 safe_rw(int fd, void const *buf, size_t count)

74 {

75  ssize_t result;

76

77  /* POSIX ограничивает COUNT значением SSIZE_MAX, но мы еще больше ограничиваем его, требуя,

78  чтобы COUNT <= INT_MAX, для избежания ошибки в Tru64 5.1.

79  При уменьшении COUNT сохраняйте указатель файла выровненным по размеру блока.

80  Обратите внимание, что read (write) может быть успешным в любом случае, даже если прочитано (записано)

81  менее COUNT байтов, поэтому вызывающий должен быть готов обработать

82  частичные результаты. */

83  if (count > INT_MAX)

84   count = INT_MAX & -8191;

85

86  do

87  {

88   result = rw(fd, buf, count);

89  }

90  while (result < 0 && IS_EINTR(errno));

91

92  return (size_t) result;

93 }

Строки 57–67 обрабатывают определения, создавая соответствующим образом safe_read() и safe_write() (см. ниже safe_write.c).

Строки 77–84 указывают на разновидность осложнений, возникающих при чтении. Здесь один особый вариант Unix не может обработать значения, превышающие INT_MAX, поэтому строки 83–84 выполняют сразу две операции: уменьшают значение числа, чтобы оно не превышало INT_MAX, и сохраняют его кратным 8192. Последняя операция служит эффективности дисковых операций: выполнение ввода/вывода с кратным основному размеру дискового блока объемом данных более эффективно, чем со случайными размерами данных. Как отмечено в комментарии, код сохраняет семантику read() и write(), где возвращенное число байтов может быть меньше затребованного.

Обратите внимание, что параметр count может и в самом деле быть больше INT_MAX, поскольку count представляет тип size_t, который является беззнаковым (unsigned). INT_MAX является чистым int, который на всех современных системах является знаковым.

Строки 86–90 представляют действительный цикл, повторно осуществляющий операцию, пока она завершается ошибкой EINTR. Макрос IS_EINTR() не показан, но он обрабатывает случай в системах, на которых EINTR не определен. (Должен быть по крайней мере один такой случай, иначе код не будет возиться с установкой макроса; возможно, это было сделано для эмуляции Unix или POSIX в не-Unix системе.) Вот safe_write.c:

1  /* Интерфейс write для повторного запуска после прерываний.

2     Copyright (С) 2002 Free Software Foundation, Inc.

   /* ...куча шаблонного материала опущена... */

17

18 #define SAFE_WRITE

19 #include "safe-read.с"

В строке 18 #define определяет SAFE_WRITE; это связано со строками 57–60 в safe_read.с.

10.4.4.2. Только GLIBC: TEMP_FAILURE_RETRY()

Файл <unistd.h> GLIBC определяет макрос TEMP_FAILURE_RETRY(), который вы можете использовать для инкапсулирования любого системного вызова, который может при неудачном вызове установить errno в EINTR. Его «объявление» следующее:

#include <unistd.h> /* GLIBC */


long int TEMP_FAILURE_RETRY(expression);

Вот определение макроса:

/*Оценить EXPRESSION и повторять, пока оно возвращает -1 с 'errno',

    установленным в EINTR. */

# define TEMP_FAILURE_RETRY(expression) \

 (__extension__ \

  ({ long int __result; \

   do __result = (long int)(expression); \

   while (__result == -1L && errno == EINTR); \

   __result; }))

Макрос использует расширение GCC к языку С (как обозначено ключевым словом __extension__), которое допускает заключенным в фигурные скобки внутри обычных скобок выражениям возвращать значение, действуя таким образом подобно простому выражению.

Используя этот макрос, мы могли бы переписать safe_read() следующим образом:

size_t safe_read(int fd, void const *buf, size_t count) {

 ssize_t result;

 /* Ограничить count, как в ранее приведенном комментарии. */

 if (count > INT_MAX)

  count = INT_MAX & ~8191;

 result = TEMP_FAILURE_RETRY(read(fd, buf, count));

 return (size_t)result;

}

10.4.5. Состояния гонок и sig_atomic_t (ISO C)

Пока обработка одного сигнала за раз выглядит просто: установка обработчика сигнала в main() и (не обязательная) переустановка самого себя обработчиком сигнала (или установка действия SIG_IGN) в качестве первого действия обработчика.

Но что произойдет, если возникнут два идентичных сигнала, один за другим? В частности, что, если ваша система восстановит действие по умолчанию для вашего сигнала, а второй сигнал появится после вызова обработчика, но до того, как он себя восстановит?

Или предположим, что вы используете bsd_signal(), так что обработчик остается установленным, но второй сигнал отличается от первого? Обычно обработчику первого сигнала нужно завершить свою работу до того, как запускается второй, а каждый обработчик сигнала не должен временно игнорировать все прочие возможные сигналы!

Оба случая относятся к состоянию гонки. Одним решением для этих проблем является как можно большее упрощение обработчиков сигналов. Это можно сделать, создав флаговые переменные, указывающие на появление сигнала. Обработчик сигнала устанавливает переменную в true и возвращается. Затем основная логика проверяет флаговую переменную в стратегических местах:

int sig_int_flag = 0; /* обработчик сигнала устанавливает в true */


void int_handler(int signum) {

 sig_int_flag = 1;

}


int main(int argc, char **argv) {

 bsd_signal(SIGINT, int_handler);

 /* ...программа продолжается... */

 if (sig_int_flag) {

  /* возник SIGINT, обработать его */

 }

 /* ...оставшаяся логика... */

}

(Обратите внимание, что эта стратегия уменьшает окно уязвимости, но не устраняет его).

Стандарт С вводит специальный тип — sig_atomic_t — для использования с такими флаговыми переменными. Идея, скрывающаяся за этим именем, в том, что присвоение значений переменным этого типа является атомарной операцией: т.е. они совершаются как одно делимое действие. Например, на большинстве машин присвоение значения int осуществляется атомарно, тогда как инициализация значений в структуре осуществляется либо путем копирования всех байтов в (сгенерированном компилятором) цикле, либо с помощью инструкции «блочного копирования», которая может быть прервана. Поскольку присвоение значения sig_atomic_t является атомарным, раз начавшись, оно завершается до того, как может появиться другой сигнал и прервать его.

Наличие особого типа является лишь частью истории. Переменные sig_atomic_t должны быть также объявлены как volatile:

volatile sig_atomic_t sig_int_flag = 0; /* обработчик сигнала устанавливает в true */

/* ...оставшаяся часть кода как раньше... */

Ключевое слово volatile сообщает компилятору, что переменная может быть изменена извне, за спиной компилятора, так сказать. Это не позволяет компилятору применить оптимизацию, которая могла бы в противном случае повлиять на правильность кода

Структурирование приложения исключительно вокруг переменных sig_atomic_t ненадежно. Правильный способ обращения с сигналами показан далее, в разделе 10.7 «Сигналы для межпроцессного взаимодействия».

10.4.6. Дополнительные предостережения

Стандарт POSIX предусматривает для обработчиков сигналов несколько предостережений:

• Что случается, когда возвращаются обработчики для SIGFPE, SIGILL, SIGSEGV или любых других сигналов, представляющих «вычислительные исключения», не определено.

• Если обработчик был вызван в результате вызова abort(), raise() или kill(), он не может вызвать raise(). abort() описана в разделе 12.4 «Совершение самоубийства: abort()», a kill() описана далее в этой главе. (Описанная далее функция API sigaction() с обработчиком сигнала, принимающая три аргумента, дает возможность сообщить об этом, если это имеет место.)

• Обработчики сигналов могут вызвать лишь функции из табл. 10.2. В частности, они должны избегать функций <stdio.h>. Проблема в том, что во время работы функции <stdio.h> может возникнуть прерывание, когда внутреннее состояние библиотечной функции находится в середине процесса обновления. Дальнейшие вызовы функций <stdio.h> могут повредить это внутреннее состояние.

Список в табл. 10.2 происходит из раздела 2.4 тома System Interfaces (Системные интерфейсы) стандарта POSIX 2001. Многие из этих функций относятся к сложному API и больше не рассматриваются в данной книге.


Таблица 10.2. Функции, которые могут быть вызваны из обработчика сигнала

_Exit() fpathconf() raise() sigqueue()
_exit() fstat() read() sigset()
accept() fsync() readlink() sigsuspend()
access() ftruncate() recv() sleep()
aio_error() getegid() recvfrom() socket()
aio_return() geteuid() recvmsg() socketpair()
aio_suspend() getgid() rename() stat()
alarm() getgroups() rmdir() sysmlink()
bind() getpeername() select() sysconf()
cfgetispeed() getpgrp() sem_post() tcdrain()
cfgetospeed() getpid() send() tcflow()
cfsetispeed() getppid() sendmsg() tcflush()
cfsetospeed() getsockname() sendto() tcgetattr()
chdir() getsockopt() setgid() tcgetpgrp()
chmod() getuid() setpgid() tcsendbreak()
chown() kill() setsid() tcsetattr()
clock_gettime() link() setsockopt() tcsetpgrp()
close() listen() setuid() time()
connect() lseek() shutdown() timer_getoverrun()
creat() lstat() sigaction() timer_gettime()
dup() mkdir() sigaddset() timer_settime()
dup2() mkfifo() sigdelset() times()
execle() open() sigemptyset() umask()
execve() pathconf() sigfillset() uname()
fchmod() pause() sigismember() unlink()
fchown() pipe() signal() utime()
fcntl() poll() sigpause() wait()
fdatasync() posix_trace_event() sigpending() waitpid()
fork() pselect() sigprocmask() write()

10.4.7. Наша история до настоящего времени, эпизод 1

Сигналы являются сложной темой, и она становится еще более сбивающей с толку. Поэтому давайте на время сделаем остановку, сделаем шаг назад и подведем итог обсужденному до сих пор:

• Сигналы являются указанием того, что произошло некоторое внешнее событие.

• raise() является функцией ISO С для отправки сигнала текущему процессу. Как отправлять сигналы другим процессам, нам еще предстоит описать.

• signal() контролирует диспозицию сигнала, т.е. реакцию процесса на сигнал, когда он появляется. Сигнал можно оставить системе для обработки по умолчанию, проигнорировать или перехватить.

• Когда сигнал перехватывается, вызывается функция-обработчик. Вот где сложность начинает поднимать свою безобразную голову:

 • ISO С не определяет, восстанавливается ли диспозиция сигнала по умолчанию до вызова обработчика или она остается на месте. Первое является поведением V7 и современных систем System V, таких, как Solaris. Последнее является поведением BSD, используемым также в GNU/Linux. (Для форсирования поведения BSD может использоваться функция POSIX bsd_signal().)

• То, что случается при прерывании сигналом системного вызова, также различается в традиционной и BSD линейках. Традиционные системы возвращают -1 с errno, установленным в EINTR. BSD системы повторно запускают системный вызов после возвращения из обработчика. Макрос GLIBC TEMP_FAILURE_RETRY() может помочь вам написать код для обработки системных вызовов, возвращающих -1 с errno, установленным в EINTR.

POSIX требует, чтобы частично выполненный системный вызов возвращал успешное завершение, указав, сколько работы было выполнено. Системный вызов, который еще не начал выполняться, вызывается повторно.

• Механизм signal() предоставляет плодотворную почву для появления условий гонки. В этой ситуации помогает тип данных ISO С sig_atomic_t, но он не решает проблему, и определенный таким способом механизм не может обезопасить от проявления условий гонки.

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

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

10.5. API сигналов System V Release 3: sigset() и др.

BSD 4.0 (примерно с 1980 г.) ввел дополнительные функции API для предоставления «надежных» сигналов.[109] В частности, стало возможным блокировать сигналы. Другими словами, программа могла сообщить ядру: «Зависни на этих конкретных сигналах в течении следующего небольшого промежутка времени, затем доставь их мне, когда я буду готов их принять». Большим преимуществом является то, что эта особенность упрощает обработчики сигналов, которые автоматически запускаются со своим заблокированным сигналом (чтобы избежать проблемы одновременной обработки двух сигналов) и, возможно, также и с другими заблокированными сигналами.

System V Release 3 (примерно с 1984 г.) приняла эти API и популяризовала их, в большинстве связанных с Unix документации и книгах вы, возможно, увидите, что на эти API ссылаются, как ведущие начало от System V Release 3. Эти функции следующие:

#include <signal.h> /* XSI */


int sighold(int sig); /* Добавить sig к маске сигналов процесса */

int sigrelse(int sig); /* Удалить sig из маски сигналов процесса */

int sigignore(int sig); /* Сокращение для sigset(sig, SIG_IGN) */

int sigpause(int sig);

 /* Приостановить процесс, позволить появиться sig */

void (*sigset(int sig, void (*disp)(int)))(int);

 /* sighandler_t sigset(int sig, sighandler_t disp); */

Стандарт POSIX для этих функций описывает их поведение в терминах маски сигналов процесса. Маска сигналов процесса отслеживает, какие сигналы (если они вообще есть) процесс заблокировал в настоящее время. Более подробно это описывается в разделе 10.6.2 «Наборы сигналов: sigset_t и связанные функции». В API System V Release 3 нет способа получить или изменить маску сигналов процесса в целом. Функции работают следующим образом:

int sighold(int sig)

Добавляет sig к списку заблокированных процессов (маска сигналов процесса).

int sigrelse(int sig)

Удаляет sig из маски сигналов процесса.

int sigignore(int sig)

Игнорирует sig. Это вспомогательная функция.

int sigpause(int sig)

Удаляет sig из маски сигналов процесса, а затем приостанавливает процесс до появления сигнала (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»).

sighandler_t sigset(int sig, sighandler_t disp)

Это замена для signal(). (Здесь мы использовали обозначение из справочной страницы GNU/Linux, чтобы упростить восприятие объявления функции.)

Для sigset() аргумент handler может быть SIG_DFL, SIG_IGN или указатель функции, как и для signal(). Однако, он может равняться также и SIG_HOLD. В этом случае sig добавляется к маске сигналов процесса, но связанное с ним действие никак не изменяется. (Другими словами, если бы у него был обработчик, он остается тем же; если было действие по умолчанию, оно не изменяется.)

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

sighold() и sigrelse() могут использоваться совместно для выделения так называемых критических секций кода: участков кода, который не должен прерываться определенным сигналом, чтобы структуры данных не повреждались кодом обработчика сигнала.

ЗАМЕЧАНИЕ. POSIX стандартизует эти API, поскольку главной целью POSIX является формализация существующей практики, где это возможно. Однако, функции sigaction(), которые вскоре будут описаны, дают вам все, что делают эти API, и даже больше. В новых программах вам не следует использовать эти API Вместо этого используйте sigaction(). (Мы заметили, что в справочной системе GNU/Linux нет даже страницы для sigset(2)!)

10.6. Сигналы POSIX

API POSIX основан на API sigvec() из BSD 4.2 и 4.3. С небольшими изменениями этот API можно было отнести к возможностям API как V7, так и System V Release 3. POSIX сделал эти изменения и переименовал API sigaction(). Поскольку интерфейс sigvec() широко не использовался, мы не будем его описывать. Вместо этого в данном разделе описывается только sigaction(), который вы и должны так или иначе использовать. (На самом деле руководства BSD 4.4 от 1994 г. помечают sigvec() как устаревшую, указывая читателю на sigaction().)

10.6.1. Обнажение проблемы

Что неладно с API System V Release 3? В конце концов, они предоставляют блокирование сигналов, так, что сигналы не теряются, и любой данный сигнал может быть надежно обработан.

Ответ в том, что этот API работает лишь с одним сигналом в одно и то же время. Программы обычно обрабатывают больше одного сигнала. И когда вы находитесь в середине процесса обработки одного сигнала, вы не хотите беспокоиться по поводу обработки еще и второго. (Предположим, вы только что начали отвечать по офисному телефону, когда зазвонил ваш мобильный телефон: вы бы предпочли, чтобы телефонная система ответила вызывающему, что в данный момент вы находитесь на другой линии и что скоро освободитесь, вместо того, чтобы проделывать все это самому.)

С API sigset() каждый обработчик сигнала должен был бы временно блокировать все другие сигналы, сделать свою работу, а затем разблокировать их. Проблема в том, что в промежутке между любыми двумя вызовами sighold() может появиться еще не заблокированный сигнал. Сценарий, еще раз, распространенный, создающий условия гонки.

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

10.6.2. Наборы сигналов: sigset_t и связанные функции

Маска сигналов процесса является списком сигналов, которые процесс в настоящее время заблокировал. Сила POSIX API в том, что маской сигналов процесса можно манипулировать атомарно, как единым целым.

Маска сигналов процесса программно представляется с помощью набора сигналов. Это тип sigset_t. Концептуально он представляет собой просто битовую маску, причем значения 0 и 1 представляют отсутствие или наличие определенного сигнала в маске.

/* Непосредственное манипулирование маской сигналов. НЕ ДЕЛАЙТЕ ЭТОГО! */

int mask = (1 << SIGHUP) | (1 << SIGINT);

 /* битовая маска для SIGHUP и SIGINT */

Однако, поскольку в системе может быть больше сигналов, чем может содержаться в одной int или long и поскольку интенсивное использование побитовых операций тяжело для восприятия, для управления наборами сигналов существует несколько функций API.

#include <signal.h> /* POSIX */


int sigemptyset(sigset_t *set);

int sigfillset(sigset_t *set);

int sigaddset(sigset_t *set, int signum);

int sigdelset(sigset_t *set, int signum);

int sigismember(const sigset_t *set, int signum);

Эти функции следующие:

int sigemptyset(sigset_t *set)

Освобождает набор сигналов. По возвращении *set не содержит сигналов. Возвращает 0 в случае успеха и -1 при ошибке.

int sigfillset(sigset_t *set)

Полностью заполняет набор сигналов. По возвращении *set содержит все сигналы, определенные системой. Возвращает 0 в случае успеха и -1 при ошибке.

int sigaddset(sigset_t *set, int signum)

Добавляет signum к маске сигналов процесса в *set. Возвращает 0 в случае успеха и -1 при ошибке.

int sigdelset(sigset_t *set, int signum)

Удаляет signum из маски сигналов процесса в *set. Возвращает 0 в случае успеха и -1 при ошибке.

int sigismember(const sigset_t *set, int signum)

Возвращает true/false, если signum присутствует или не присутствует в *set.

Перед выполнением с переменной sigset_t каких-то действий всегда следует вызывать одну из функций sigemptyset() или sigfillset(). Существуют оба интерфейса, поскольку иногда бывает нужно начать с пустого набора и работать потом лишь с одним или двумя сигналами, а в другое время бывает нужно работать со всеми сигналами, возможно, убирая один или два сигнала.

10.6.3. Управление маской сигналов: sigprocmask() и др.

Маска сигналов процесса вначале пуста - заблокированных сигналов нет. (Это упрощение; см. раздел 10.9 «Сигналы, передающиеся через fork() и exec().) Три функции позволяют работать непосредственно с маской сигналов процесса:

#include <signal.h> /* POSIX */


int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

int sigpending(sigset_t *set);

int sigsuspend(const sigset_t *set);

Функции следующие:

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)

Если oldset не равен NULL, получается маска сигналов текущего процесса и помещается в *oldset. Затем маска сигналов процесса обновляется в соответствии с содержимым set и значением how, который должен иметь одно из следующих значений:

SIG_BLOCK  Объединить сигналы в *set с маской сигналов текущего процесса. Новая маска является объединением текущей маски и *set.

SIG_UNBLOCK  Удалить сигналы в *set из маски сигналов процесса. Это не представляет проблемы, если *set содержит сигнал, который не содержится в текущей маске сигналов процесса.

SIG_SETMASK  Заменить маску сигналов процесса содержимым *set.

Если set равен NULL, a oldset — нет, значение how неважно. Эта комбинация получает маску сигналов текущего процесса, не меняя ее. (Это явно выражено в стандарте POSIX, но не ясно из справочной страницы GNU/Linux.)

int sigpending(sigset_t *set)

Эта функция позволяет увидеть, какие сигналы ожидают решения; т.е. *set заполнен этими сигналами, которые были посланы, но они еще не доставлены, поскольку заблокированы.

int sigsuspend(const sigset_t *set)

Эта функция временно заменяет маску сигналов процесса содержимым *set, а затем приостанавливает процесс, пока сигнал не будет получен. По определению, заставить функцию вернуться может только сигнал, не находящийся в *set (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия).

10.6.4. Перехват сигналов: sigaction()

Наконец мы готовы взглянуть на функцию sigaction(). Эта функция сложна, и мы намеренно опускаем множество деталей, которые предназначены для специального использования. Стандарт POSIX и справочная страница sigaction(2) предоставляют все подробности, хотя вы должны тщательно прочесть и то, и другое, чтобы полностью все усвоить.

#include <signal.h> /* POSIX */


int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);

Аргументы следующие:

int signum

Интересующий сигнал, как в случае с другими функциями обработки сигналов.

const struct sigaction *act

Определение нового обработчика для сигнала signum.

struct sigaction *oldact

Определение текущего обработчика. Если не NULL, система до установки *act заполняет *oldact. *act может быть NULL, в этом случае *oldact заполняется, но больше ничего не меняется.

Таким образом, sigaction() и устанавливает новый обработчик, и получает старый за одно действие. struct sigaction выглядит следующим образом.

/* ПРИМЕЧАНИЕ: Порядок в структуре может варьировать. Могут быть

   также и другие поля! */

struct sigaction {

 sigset_t sa_mask; /* Дополнительные сигналы для блокирования */

 int sa_flags;     /* Контролирует поведение */

 void (*sa_handler)(int);

  /* Может образовать объединение с sa_sigaction */

 void (*sa_sigaction)(int, siginfo_t*, void*);

  /* Может образовать объединение с sa_handler */

}

Поля следующие:

sigset_t sa_mask

Набор дополнительных сигналов для блокирования при запуске функции обработчика. Таким образом, когда вызывается обработчик, общий набор заблокированных сигналов является объединением сигналов в маске процесса, сигналов в act->mask и, если SA_NODEFER сброшен, signum.

int sa_flags

Флаги, контролирующие обработку сигнала ядром. См. обсуждение далее.

void (*sa_handler)(int)

Указатель на «традиционную» функцию обработчика. У нее такой же прототип (возвращаемый тип и список параметров), как у функции обработчика для signal(), bsd_signal() и sigset().

void (*sa_sigaction)(int, siginfo_t*, void*)

Указатель на функцию обработчика «нового стиля». Функция принимает три аргумента, которые вскоре будут описаны.

Которая из функций act->sa_handler и act->sa_sigaction используется, зависит от флага SA_SIGINFO в act->sa_flags. Когда имеется, используется act->sa_sigaction; в противном случае используется act->sa_handler. Как POSIX, так и справочная страница GNU/Linux указывают, что эти два поля могут перекрываться в памяти (т. е. быть частью union). Таким образом, никогда не следует использовать оба поля в одной и той же struct sigaction.

Поле sa_flags составляется с помощью побитового ИЛИ значений одного или более флагов, перечисленных в табл. 10.3.


Таблица 10.3. Значения флагов для sa_flags

Флаг Значение
SA_NOCLDSTOP Этот флаг имеет смысл лишь для SIGCHLD. Когда он установлен, родитель не получает сигнал при остановке порожденною процесса сигналами SIGSTOP, SIGTSTP, SIGTTIN или SIGTTOU. Эти сигналы обсуждаются позже, в разделе 10.8.2
SA_NOCLDWAIТ Этот флаг имеет смысл лишь для SIGCHLD. Его поведение сложно. Мы отложим объяснение на потом, см. раздел 10.8.3
SA_NODEFER Обычно данный сигнал блокируется, когда вызывается обработчик сигнала. Когда установлен один из этих флагов, данный сигнал не блокируется при запуске обработчика SA_NODEFER является официальным именем POSIX данного флага (которое и следует использовать)
SA_NOMASK Альтернативное имя для SA_NODEFER[110]
SA_SIGINFO Обработчик сигнала принимает три аргумента. Как упоминалось, при данном установленном флаге должно использоваться поле sa_sigaction вместо sa_handler.
SA_ONSTACK Это продвинутая возможность. Обработчики сигналов могут вызываться с использованием предоставленной пользователем памяти в качестве «альтернативного стека сигнала». Эта память даётся ядру для подобного использования посредством sigaltstack() (см. sigaltstack(2)). Эта особенность больше не описывается в данной книге
SA_RESETHAND Этот флаг обеспечивает поведение V7: после вызова обработчика восстанавливается действие сигнала по умолчанию. Официальным именем POSIX флага (которое следует использовать) является SA_RESETHAND
SA_ONESHOT Альтернативное имя для SA_RESETHAND.
SA_RESTART Этот флаг предоставляет семантику BSD: системные вызовы, которые могут завершиться с ошибкой EINTR и которые получают этот сигнал, запускаются повторно.
Когда в act->sa_flags установлен флаг SA_SIGINFO, поле act->sa_sigaction является указателем на функцию, объявленную следующим образом:

void action_handler(int sig, siginfo_t *info, void *context) {

 /* Здесь тело обработчика */

}

Структура siginfo_t предоставляет изобилие сведений о сигнале:

/* Определение POSIX 2001. Действительное содержание может на разных системах быть разным. */

typedef struct {

 int si_signo;  /* номер сигнала */

 int si_errno;  /* значение <errno.h> при ошибке */

 int si_code;   /* код сигнала; см. текст */

 pid_t si_pid;  /* ID процесса, пославшего сигнал */

 uid_t si_uid;  /* настоящий UID посылающего процесса */

 void *si_addr; /* адрес вызвавшей ошибку инструкции */

 int si_status; /* значение завершения, может включать death-by-signal */

 long si_band;  /* связывающее событие для SIGPOLL/SIGIO */

 union sigval si_value; /* значение сигнала (расширенное) */

} siginfo_t;

Поля si_signo, si_code и si_value доступны для всех сигналов. Другие поля могут быть членами объединения, поэтому должны использоваться лишь для тех сигналов, для которых они определены. В структуре siginfo_t могут быть также и другие поля.

Почти все поля предназначены для расширенного использования. Все подробности содержатся в стандарте POSIX и справочной странице sigaction(2). Однако, мы можем описать простое использование поля si_code.

Для SIGBUS, SIGCHLD, SIGFPE, SIGILL, SIGPOLL, SIGSEGV и SIGTRAP поле si_code может принимать любое из набора предопределенных значений, специфичных для каждого сигнала, указывая на причину появления сигнала. Откровенно говоря, детали несколько чрезмерны; повседневному коду на самом деле нет необходимости иметь с ними дела (хотя позже мы рассмотрим значения для SIGCHLD). Для всех остальных сигналов член si_code имеет одно из значений из табл. 10.4.


Таблица 10.4. Значения происхождения сигнала для si_code

Значение Только GLIBC Смысл
SI_ASYNCIO Асинхронный ввод/вывод завершен (расширенный).
SI_KERNEL Сигнал послан ядром.
SI_MESGQ Состояние очереди сообщений изменилось (расширенный.)
SI_QUEUE Сигнал послан из sigqueue() (расширенный).
SI_SIGIO SIGIO поставлен в очередь (расширенный).
SI_TIMER Время таймера истекло
SI_USER Сигнал послан функцией kill(). raise() и abort() также могут его вызвать, но это не обязательно.
В особенности полезно значение SI_USER; оно позволяет обработчику сигнала сообщить, был ли сигнал послан функциями raise() или kill() (описываются далее). Вы можете использовать эту информацию, чтобы избежать повторного вызова raise() или kill().

Третий аргумент обработчика сигнала с тремя аргументами, void *context, является расширенной возможностью, которая больше не обсуждается в данной книге.

Наконец, чтобы увидеть sigaction() в действии, исследуйте полный исходный код обработчика сигнала для sort.c:

2074 static void

2075 sighandler(int sig)

2076 {

2077 #ifndef SA_NOCLDSTOP /* В системе старого стиля... */

2078  signal(sig, SIG_IGN); /* - для игнорирования sig используйте signal()*/

2079 #endif - /* В противном случае sig автоматически блокируется */

2080

2081  cleanup(); /* Запуск кода очистки */

2082

2083 #ifdef SA_NOCLDSTOP /* В системе в стиле POSIX... */

2084  {

2085   struct sigaction sigact;

2086

2087   sigact.sa_handler = SIG_DFL; /* - Установить действие по умолчанию */

2088   sigemptyset(&sigact.sa_mask); /* - Нет дополнительных сигналов для блокирования */

2089   sigact.sa_flags = 0; /* - Специальные действия не предпринимаются */

2090   sigaction(sig, &sigact, NULL); /* - Поместить на место */

2091  }

2092 #else /* На системе в старом стиле... */

2093  signal(sig, SIG_DFL); /* - Установить действие по умолчанию */

2094 #endif

2095

2096  raise(sig); /* Повторно послать сигнал */

2097 }

Вот код в main(), который помещает обработчик на свое место:

2214 #ifdef SA_NOCLDSTOP /* На системе POSIX... */

2215 {

2216  unsigned i;

2217  sigemptyset(&caught_signals);

2218  for (i = 0; i < nsigs; i++) /* - Блокировать все сигналы */

2219   sigaddset(&caught_signals, sigs[i]);

2220  newact.sa_handler = sighandler; /* - Функция обработки сигнала */

2221  newact.sa_mask = caught_signals; /* - Установить для обработчика маску сигналов процесса */

2222  newact.sa_flags =0; /* - Особых флагов нет */

2223 }

2224 #endif

2225

2226 {

2227  unsigned i;

2228  for (i = 0; i < nsigs; i++) /* Для всех сигналов... */

2229  {

2230   int sig = sigs[i];

2231 #ifdef SA_NOCLDSTOP

2232   sigaction(sig, NULL, &oldact); /* - Получить старый обработчик */

2233   if (oldact.sa_handler != SIG_IGN) /* - Если этот сигнал не игнорируется */

2234    sigaction(sig, &newact, NULL); /* - Установить наш обработчик */

2235 #else

2236   if (signal(sig, SIG_IGN) != SIG_IGN)

2237    signal(sig, sighandler); /* - Та же логика со старым API */

2238 #endif

2239  }

2240 }

Мы заметили, что строки 2216–2219 и 2221 могут быть замещены одним вызовом: sigfillset(&newact.sa_mask);

Мы не знаем, почему код написан именно таким способом.

Интерес представляют также строки 2233–2234 и 2236–2237, которые показывают правильный способ проверки того, игнорируется ли сигнал, и для установки обработчика лишь в том случае, если сигнал не игнорируется.

ЗАМЕЧАНИЕ. Функции API sigaction() и signal() не должны использоваться вместе для одного и того же сигнала. Хотя POSIX идет на большие длинноты, чтобы сначала сделать возможным использование signal(), получить struct sigaction, представляющую диспозицию signal(), и восстановить ее, все равно это плохая мысль. Код будет гораздо проще читать, писать и понимать, если вы используете одну функцию или другую взаимоисключающим образам

10.6.5. Извлечение ожидающих сигналов: sigpending()

Описанный ранее системный вызов sigpending() позволяет получить набор ожидающих сигналов, т.е тех сигналов, которые появились, но еще не доставлены из-за блокировки:

#include <signal.h> /* POSIX */


int sigpending(sigset_t *set);

Помимо разблокировки ожидающих сигналов, чтобы они могли быть доставлены, вы можете решить их игнорировать. Установка действия сигнала SIG_IGN вызывает сбрасывание сигнала (даже если он был заблокирован). Сходным образом для тех сигналов, действием по умолчанию для которых является их игнорирование, установка действия в SIG_DFL также вызывает сбрасывание таких ожидающих сигналов.

10.6.6. Создание возможности для прерывания функций: siginterrupt()

Чтобы сделать определенную функцию прерываемой или повторно запускаемой в зависимости от значения второго аргумента, в качестве удобного средства может использоваться функция siginterrupt(). Объявление следующее:

#include <signal.h> /* XSI */


int siginterrupt(int sig, int flag);

В соответствии со стандартом POSIX поведение siginterrupt() эквивалентно следующему коду:

int siginterrupt(int sig, int flag) {

 int ret;

 struct sigaction act;

 (void)sigaction(sig, NULL, &act); /* Получить старые установки */

 if (flag) /* Если flag равен true... */

  act.sa_flags &= ~SA_RESTART; /* Запретить повторный запуск */

 else /* В противном случае... */

  act.sa_flags |= SA_RESTART; /* Разрешить повторный запуск */

 ret = sigaction(sig, &act, NULL);

  /* Поместить новые установки на место */

 return ret; /* Вернуть результат */

}

В случае успеха возвращаемое значение равно 0 и -1 при ошибке.

10.6.7. Передача сигналов: kill() и killpg()

Традиционная функция Unix для передачи сигналов называется kill(). Имя несколько неправильное; все, что она делает — отправляет сигнал. (Результатом этого часто является завершение получателя сигнала, но это не обязательно верно. Однако, теперь слишком поздно менять имя.) Функция killpg() посылает сигнал определенной группе процессов. Объявления следующие:

#include <sys/types.h> /* POSIX */

#include <signal.h>


int kill(pid_t pid, int sig);

int killpg(int pgrp, int sig); /* XSI */

Аргумент sig является либо именем сигнала, либо 0. В последнем случае сигнал не посылается, но ядро все равно осуществляет проверку ошибок. В частности, это правильный способ проверки существования данного процесса или группы, а также проверки того, что у вас есть разрешение на передачу сигналов процессу или группе процессов kill() возвращает 0 в случае успеха и -1 при ошибке; errno указывает на проблему.

Правила для значения pid несколько запутаны:

pid > 0   pid является номером процесса, и сигнал посылается этому процессу

pid = 0   Сигнал посылается каждому процессу в группе посылающего процесса.

pid = -1  Сигнал посылается каждому процессу в системе, за исключением специальных системных процессов. Применяется проверка прав доступа. На системах GNU/Linux исключается лишь процесс init (PID 1), но у других систем могут быть другие специальные процессы.

pid < -1  Сигнал посылается группе процессов, представленной абсолютным значением pid. Таким образом, вы можете отправить сигнал всей группе процессов, дублируя возможности killpg(). Эта неортогональность обеспечивает историческую совместимость.

Значение pid для kill() сходно со значением для waitpid() (см. раздел 9.1.6.1 «Использование функций POSIX: wait() и waitpid()»).

Стандартная функция С raise() в сущности эквивалентна

int raise(int sig) {

 return kill(getpid(), sig);

}

Комитет по стандартизации С выбрал имя raise(), поскольку С должен работать также в окружениях, не относящихся к Unix, a kill() была сочтена специфичной для Unix функцией. Представилась также возможность дать этой функции более описательное имя.

killpg() посылает сигнал группе процессов. Пока значение pgrp превышает 1, эта функция эквивалентна 'kill(-pgrp, sig)'. Справочная страница GNU/Linux killpg(2) утверждает, что если pgrp равно 0, сигнал посылается группе отправляющего процесса (Это то же самое, что и kill().)

Как вы могли представить, нельзя послать сигнал произвольному процессу (если вы не являетесь суперпользователем, root). Для обычных пользователей действительный или эффективный UID отправляющего процесса должен соответствовать действительному или сохраненному set-user-ID получающего процесса. (Различные UID описаны в разделе 11.1.1 «Действительные и эффективные ID».)

Однако SIGCONT является особым случаем: пока получающий процесс является членом того же сеанса, что и отправляющий, сигнал пройдет. (Сеансы были кратко описаны в разделе 9.2.1 «Обзор управления заданиями».) Это особое правило позволяет управляющей заданиями оболочке продолжать остановленные процессы-потомки, даже если этот остановленный процесс имеет другой ID пользователя.

10.6.8. Наша история до настоящего времени, эпизод II

System V Release 3 API был предназначен для исправления различных проблем, представленных первоначальным API сигналов V7. В частности, важной дополнительной концепцией является понятие о блокировке сигналов.

Однако, этот API оказался недостаточным, поскольку он работал лишь с одним сигналом за раз, оставляя множество широко открытых окон, через которые могли поступать нежелательные сигналы. POSIX API, работая атомарно с множеством сигналов (маской сигналов процесса, программно представленной типом sigset_t), решает эту проблему, закрывая окна.

Первый набор функций, который мы исследовали, манипулирует значениями sigset_t: sigfillset(), sigemptyset(), sigaddset(), sigdelset() и sigismember().

Следующий набор работает с маской сигналов процесса: sigprocmask() устанавливает и получает маску сигналов процесса, sigpending() получает набор ожидающих сигналов, a sigsuspend() помещает процесс в состояние сна, временно заменяя маску сигналов процесса одним из своих параметров.

Функция POSIX API sigaction() (весьма) запутана из-за необходимости обеспечить:

• обратную совместимость: SA_RESETHAND и SA_RESTART в поле sa_flags;

• выбор, блокировать также полученный сигнал или нет: SA_NODEFER для sa_flags;

• возможность иметь два различных вида обработчиков сигналов: с одним или с тремя аргументами;

• выбор поведения для управления SIGCHLD: SA_NOCLDSTOP и SA_NOCLDWAIT для sa_flags.

Функция siginterrupt() является удобной для разрешения или запрещения повторного запуска системных вызовов для данного сигнала.

Наконец, для посылки сигналов не только текущему, но также и другим процессам могут использоваться kill() и killpg() (конечно, с проверкой прав доступа).

10.7. Сигналы для межпроцессного взаимодействия

«ЭТО УЖАСНАЯ МЫСЛЬ! СИГНАЛЫ НЕ ПРЕДНАЗНАЧЕНЫ ДЛЯ ЭТОГО! Просто скажите НЕТ».

- Джефф Колье (Geoff Collyer) -
Одним из главных механизмов межпроцессного взаимодействия (IPC) являются каналы, которые описаны в разделе 9.3 «Базовая межпроцессная коммуникация каналы и FIFO». Сигналы также можно использовать для очень простого IPC[111]. Это довольно грубо; получатель может лишь сказать, что поступил определенный сигнал. Хотя функция sigaction() позволяет получателю узнать PID и владельца процесса, пославшего сигнал, эти сведения обычно не очень помогают.

ЗАМЕЧАНИЕ. Как указывает цитата в начале, использование сигналов для IPC почти всегда является плохой мыслью. Мы рекомендуем по возможности избегать этого. Но нашей целью является научить вас, как использовать возможности Linux/Unix, включая их отрицательные моменты, оставляя за вами принятие информированного решения, что именно использовать.

Сигналы в качестве IPC для многих программ могут быть иногда единственным выбором. В частности, каналы не являются альтернативой, если две взаимодействующие программы не запущены общим родителем, а файлы FIFO могут не быть вариантом, если одна из взаимодействующих программ работает лишь со стандартными вводом и выводом. (Примером обычного использования сигналов являются определенные системные программы демонов, таких, как xinetd, которые принимают несколько сигналов, уведомляющих, что нужно повторно прочесть файл настроек, осуществить проверку непротиворечивости и т.д. См. xinetd(8) в системе GNU/Linux и inetd(8) в системе Unix.)

Типичная высокоуровневая структура основанного на сигналах приложения выглядит таким образом:

for(;;){

 /* Ожидание сигнала */

 /* Обработка сигнала */

}

Оригинальным интерфейсом V7 для ожидания сигнала является pause():

#include <unistd.h> /* POSIX */


int pause(void);

pause() приостанавливает процесс; она возвращается лишь после того, как сигнал будет доставлен и его обработчик вернется из вызова. По определению, pause() полезна лишь с перехваченными сигналами — игнорируемые сигналы при их появлении игнорируются, а сигналы с действием по умолчанию, завершающим процесс (с созданием файла образа или без него), продолжают действовать так же.

Проблема в только что описанной высокоуровневой структуре приложения кроется в части «Обработка сигнала». Когда этот код запускается, вы не захотите обрабатывать другой сигнал; вы хотите завершить обработку текущего сигнала до перехода к следующему. Одним из возможных решений является структурирование обработчика сигнала таким образом, что он устанавливает флаг и проверяет его в главном цикле: volatile sig_atomic_t signal_waiting = 0; /* true, если не обрабатываются сигналы */


void handler(int sig) {

 signal_waiting = 1;

 /* Установка других данных, указывающих вид сигнала */

В основном коде флаг проверяется:

for (;;) {

 if (!signal_waiting) { /* Если возник другой сигнал, */

  pause(); /* этот код пропускается */

  signal_waiting = 1;

 }

 /* Определение поступившего сигнала */

 signal_waiting = 0;

 /* Обработка сигнала */

}

К сожалению, этот код изобилует условиями гонки:

for (;;) {

 if (!signal_waiting) {

  /* <--- Сигнал может появиться здесь, после проверки условия! */

  pause(); /* pause() будет вызвана в любом случае */

  signal_waiting = 1;

 }


 /* Определение поступившего сигнала

    <--- Сигнал может переписать здесь глобальные данные */

 signal_waiting = 0;

 /* Обработка сигнала

    <--- То же и здесь, особенно для нескольких сигналов */

}

Решением является блокирование интересующего сигнала в любое время, кроме ожидания его появления. Например, предположим, что интересующим нас сигналом является SIGINT:

void handler(int sig) {

 /* sig автоматически блокируется функцией sigaction() */

 /* Установить глобальные данные, касающиеся этого сигнала */

}


int main(int argc, char **argv) {

 sigset_t set;

 struct sigaction act;


 /* ...обычная настройка, опции процесса и т.д. ... */


 sigemptyset(&set); /* Создать пустой набор */

 sigaddset(&set, SIGINT); /* Добавить в набор SIGINT */

 sigprocmask(SIG_BLOCK, &set, NULL); /* Заблокировать его */


 act.sa_mask = set; /* Настроить обработчик */

 act.sa_handler = handler;

 act.sa_flags = 0;

 sigaction(sig, &act, NULL); /* Установить его */


 ... /* Возможно, установить отдельные обработчики */

 ... /* для других сигналов */


 sigemptyset(&set); /* Восстановить пустой, допускает SIGINT */


 for (;;) {

  sigsuspend(&set); /* Ждать появления SIGINT */

  /* Обработка сигнала. SIGINT здесь снова блокируется */

 }

 /* ...любой другой код... */

 return 0;

}

Ключом к использованию этого является то, что sigsuspend() временно заменяет маску сигналов процесса маской, переданной в аргументе. Это дает SIGINT возможность появиться. При появлении он обрабатывается; обработчик сигнала возвращается, а вслед за ним возвращается также sigsuspend(). Ко времени возвращения sigsuspend() первоначальная маска процесса снова на месте.

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

При наличии всего этого не следует в новом коде использовать pause(). pause() был стандартизован POSIX главным образом для поддержки старого кода. То же самое верно и для функции sigpause() System V Release 3. Вместо этого, если нужно структурировать свое приложение с использованием сигналов для IPC, используйте исключительно функции API sigsuspend() и sigaction().

ЗАМЕЧАНИЕ. Приведенный выше код предполагает, что маска сигналов процесса начинается пустой. Код изделия должен вместо этого работать с любой маской сигналов, имеющейся на момент запуска программы.

10.8. Важные сигналы специального назначения

Некоторые сигналы имеют особое назначение. Здесь мы опишем наиболее важные.

10.8.1. Сигнальные часы: sleep(), alarm() и SIGALARM

Часто бывает необходимо написать программу в виде

while (/* некоторое неверное условие */) {

 /* подождать некоторое время */

}

Часто такая потребность возникает в сценариях оболочки, например, в ожидании регистрации определенного пользователя:

until who | grep '^arnold' > /dev/null

do

 sleep 10

done

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

10.8.1.1. Труднее, но с большим контролем: alarm() и SIGALARM

Основным строительным блоком является системный вызов alarm():

#include <unistd.h> /* POSIX */


unsigned int alarm(unsigned int seconds);

После того, как alarm() возвратится, программа продолжает работать. Однако, когда истекают seconds секунд, ядро посылает процессу SIGALARM. Действием по умолчанию является завершение процесса, но вы скорее всего вместо этого установите обработчик сигнала для SIGALARM.

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

Преимуществом здесь является то, что со своим установленным обработчиком вы можете делать при поступлении сигнала все, что хотите. Недостаток же в том, что приходится быть готовым к работе в нескольких контекстах: основном контексте и контексте обработчика сигнала.

10.8.1.2. Простой и легкий: sleep()

Более легкий способ ожидания истечения фиксированного промежутка времени заключается в использовании функции sleep():

#include <unistd.h> /* POSIX */


unsigned int sleep(unsigned int seconds);

Возвращаемое значение равно 0, если процесс проспал все отведенное время. В противном случае возвращается оставшееся для сна время. Это последнее значение может возникнуть в случае, если появился сигнал, пока процесс дремал.

ЗАМЕЧАНИЕ. Функция sleep() часто реализуется через сочетание signal(), alarm() и pause(). Такой подход делает опасным смешивание sleep() с вашим собственным вызовом alarm() (или расширенной функцией setitimer(), описанной в разделе 14.3.3 «Интервальные таймеры setitimer() и getitimer()») Чтобы теперь узнать о функции nanosleep(), см. раздел 14.3.4 «Более точные паузы: nanosleep()».

10.8.2. Сигналы, управляющие заданиями

Несколько сигналов используются для реализации управления заданиями — возможностью начинать и останавливать задания и перемещать их из фонового режима на передний план и обратно. На уровне пользователя вы, несомненно, проделывали это: использовали CTRL-Z для остановки задания, bg для помещения его в фоновый режим, а иногда использовали fg для перемещения фонового или остановленного задания на передний план.

Секция 9.2.1 «Обзор управления заданиями» описывает в общем, как осуществляется управление заданиями. Данный раздел завершает обзор, описав сигналы управления заданиями. поскольку иногда может понадобиться перехватить их непосредственно:

SIGTSTP

Этот сигнал осуществляет «остановку терминала». Это сигнал, который ядро посылает процессу, когда пользователь за терминалом (или окном, эмулирующим терминал) набирает определенный ключ. Обычно это CTRL-Z, аналогично тому, как CTRL-C обычно посылает SIGINT.

Действием по умолчанию для SIGTSTP является остановка (переход в приостановленное состояние) процесса. Однако, вы можете перехватить этот сигнал, как любой другой. Хорошая мысль сделать это, если ваша программа изменяет состояние терминала. Например, рассмотрите экранные редакторы vi или Emacs, которые переводят терминал в посимвольный режим. По получении SIGTSTP, они должны восстановить терминал в его нормальный построчный режим, а затем приостановиться сами.

SIGSTOP

Этот сигнал также останавливает процесс, но он не может быть перехвачен, заблокирован или проигнорирован. Он может быть использован в качестве последнего средства вручную (посредством команды kill) или программным путем. Например, только что обсужденный обработчик SIGTSTP после восстановления состояния терминала мог бы затем использовать для остановки процесса 'raise (SIGSTOP)'.

SIGTTIN, SIGTTOU

Ранее эти сигналы были определены как «фоновое чтение из tty» и «фоновая запись в tty». tty является устройством терминала. В системах управления заданиями процессы, работающие в фоновом режиме, заблокированы от попыток чтения с терминала или записи в него. Когда процесс пытается осуществить любую из этих операций, ядро посылает ему соответствующий сигнал. Для обоих действием по умолчанию является остановка процесса. При желании можно перехватить эти сигналы, но для этого редко бывает необходимость.

SIGCONT

Этот сигнал вновь запускает остановленный процесс. Если процесс не остановлен, он игнорируется. При желании его можно перехватить, но опять-таки для большинства программ мало причин для осуществления этого. Продолжая наш пример, обработчик SIGCONT для экранного редактора должен перед возвращением вернуть терминал обратно в посимвольный режим.

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

10.8.3. Родительский надзор: три различные стратегии

Как описано в разделе 9.1.1 «Создание процесса: fork()», одним побочным эффектом вызова fork() является создание между процессами отношений родитель-потомок. Родительский процесс может ждать завершения одного или более из своих потомков и получить статус завершения порожденного процесса посредством одного из семейства системных вызовов wait().

Завершившиеся порожденные процессы, которых никто не ожидал, называются зомби (zombies). Обычно каждый раз при завершении порожденного процесса ядро посылает родительскому процессу сигнал SIGCHLD[112]. Действием по умолчанию является игнорирование этого сигнала. В этом случае процессы зомби накапливаются до тех пор, пока родитель не вызовет wait() или не закончится сам. В последнем случае процессы зомби получают в качестве нового родителя системный процесс init (PID 1), который получает от них результаты как часть своей обычной работы. Сходным образом, активные потомки также получают родителем init, и их результаты будут собраны при их завершении.

SIGCHLD используется для большего, чем уведомление о завершении потомка. Каждый раз при остановке потомка (посредством одного из обсужденных ранее сигналов управления заданиями) родителю также посылается SIGCHLD. Стандарт POSIX указывает, что SIGCHLD «может быть послан» также, когда помок вновь запускается; очевидно, среди оригинальных Unix-систем имеются различия.

Сочетание флагов для поля sa_flags  в struct sigation и использование SIG_IGN в качестве действия для SIGCHLD позволяет изменить способ обработки ядром остановок, возобновления или завершения потомков.

Как и с сигналами в общем, описанные здесь интерфейсы и механизмы сложны, поскольку они развивались с течением времени.

10.8.3.1. Плохие родители: полное игнорирование потомков

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

Другой возможностью, дающей такой же результат, является использование флага SA_NOCLDWAIТ. В коде:

/* Старый стиль: */        /* Новый стиль: */

signal(SIGCHLD, SIG_IGN);  struct sigaction sa;

                           sa.sa_handler = SIG_IGN;

                           sa.sa_flags = SA_NOCLDWAIT;

                           sigemptyset(&sa.sa_mask);

                           sigaction(SIGCHLD, &sa, NULL);

10.8.3.2. Снисходительные родители: минимальный надзор

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

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

Следующая программа, ch10-reap1.с, блокирует SIGCHLD до тех пор, пока не будет готова восстановить потомков.

1  /* ch10-reap1.с --- демонстрирует управление SIGCHLD с использованием цикла */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <signal.h>

6  #include <string.h>

7  #include <sys/types.h>

8  #include <sys/wait.h>

9

10 #define MAX_KIDS 42

11 #define NOT_USED -1

12

13 pid_t kids[MAX_KIDS];

14 size_t nkids = 0;

Массив потомков отслеживает ID порожденных процессов. Если элемент содержит NOT_USED, он не представляет необработанного потомка. (Его инициализируют строки 89–90 внизу) nkids указывает, сколько значений в kids следует проверить.

16 /* format_num --- вспомогательная функция, поскольку нельзя использовать [sf]printf() */

17

18 const char *format_num(int num)

19 {

20 #define NUMSIZ 30

21  static char buf[NUMSIZ];

22  int i;

23

24  if (num <= 0) {

25   strcpy(buf, "0");

26   return buf;

27  }

28

29  i = NUMSIZ - 1;

30  buf[i--] = '\0';

31

32  /* Преобразует цифры обратно в строку. */

33  do {

34   buf[i--] = (num % 10) + '0';

35   num /= 10;

36  } while (num > 0);

37

38  return &buf[i+1];

39 }

Поскольку обработчики сигналов не должны вызывать функции семейства printf(), мы предусмотрели для преобразования десятичного сигнала или номера PID в строку простую «вспомогательную» функцию format_num(). Это примитивно, но работает.

41 /* childhandler --- перехват SIGCHLD, сбор сведений со всех доступных потомков */

42

43 void childhandler(int sig)

44 {

45  int status, ret;

46  int i;

47  char buf[100];

48  static const char entered[] = "Entered childhandler\n" ;

49  static const char exited[] = "Exited childhandler\n";

50

51  writed, entered, strlen(entered));

52  for (i =0; i < nkids; i++) {

53   if (kids[i] == NOT_USED)

54    continue;

55

56 retry:

57   if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {

58    strcpy(buf, "\treaped process ");

59    strcat(buf, format_num(ret));

60    strcat(buf, "\n");

61    write(1, buf, strlen(buf));

62    kids[i] = NOT_USED;

63   } else if (ret == 0) {

64    strcpy(buf, "\tpid ");

65    strcat(buf, format_num(kids[i]));

66    strcat(buf, " not available yet\n");

67    write(1, buf, strlen(buf));

68   } else if (ret == -1 && errno == EINTR) {

69    write(1, "\tretrying\n", 10);

70    goto retry;

71   } else {

72    strcpy(buf, "\twaitpid() failed: ");

73    strcat(buf, strerror(errno));

74    strcat(buf, "\n");

75    write(1, buf, strlen(buf));

76   }

77  }

78  write(1, exited, strlen(exited));

79 }

Строки 51 и 58 выводят «входное» и «завершающее» сообщения, так что мы можем ясно видеть, когда вызывается обработчик сигнала. Другие сообщения начинаются с ведущего символа TAB.

Главной частью обработчика сигнала является большой цикл, строки 52–77. Строки 53–54 проверяют на NOT_USED и продолжают цикл, если текущий слот не используется.

Строка 57 вызывает waitpid() с PID текущего элемента kids. Мы предусмотрели опцию WNOHANG, которая заставляет waitpid() возвращаться немедленно, если затребованный потомок недоступен. Этот вызов необходим, так как возможно, что не все потомки завершились.

Основываясь на возвращенном значении, код предпринимает соответствующее действие. Строки 57–62 обрабатывают случай обнаружения потомка, выводя сообщение и помещая в соответствующий слот в kids значение NOT_USED.

Строки 63–67 обрабатывают случай, когда затребованный потомок недоступен. В этом случае возвращается значение 0, поэтому выводится сообщение, и выполнение продолжается.

Строки 68–70 обрабатывают случай, при котором был прерван системный вызов. В этом случае самым подходящим способом обработки является goto обратно на вызов waitpid(). (Поскольку main() блокирует все сигналы при вызове обработчика сигнала [строка 96], это прерывание не должно случиться. Но этот пример показывает, как обработать все случаи.)

Строки 71–76 обрабатывают любую другую ошибку, выводя соответствующее сообщение об ошибке.

81  /* main --- установка связанных с порожденными процессами сведений и сигналов, создание порожденных процессов */

82

83  int main(int argc, char **argv)

84  {

85   struct sigaction sa;

86   sigset_t childset, emptyset;

87   int i;

88

89   for (i = 0; i < nkids; i++)

90    kids[i] = NOT_USED;

91

92   sigemptyset(&emptyset);

93

94   sa.sa_flags = SA_NOCLDSTOP;

95   sa.sa_handler = childhandler;

96   sigfillset(&sa.sa_mask); /* блокировать все при вызове обработчика */

97   sigaction(SIGCHLD, &sa, NULL);

98

99   sigemptyset(&childset);

100  sigaddset(&childset, SIGCHLD);

101

102  sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */

103

104  for (nkids = 0; nkids < 5; nkids++) {

105   if ((kids[nkids] = fdrk()) == 0) {

106    sleep(3);

107    _exit(0);

108   }

109  }

110

111  sleep(5); /* дать потомкам возможность завершения */

112

113  printf("waiting for signal\n");

114  sigsuspend(&emptyset);

115

116  return 0;

117 }

Строки 89–90 инициализируют kids. Строка 92 инициализирует emptyset. Строки 94–97 настраивают и устанавливают обработчик сигнала для SIGCHLD. Обратите внимание на использование в строке 94 SA_NOCLDSTOP, тогда как строка 96 блокирует все сигналы при вызове обработчика.

Строки 99–100 создают набор сигналов, представляющих SIGCHLD, а строка 102 устанавливает их в качестве маски сигналов процесса для программы.

Строки 104–109 создают пять порожденных процессов, каждый из которых засыпает на три секунды. По ходу дела они обновляют массив kids и переменную nkids.

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

Наконец, строки 113–114 выводят сообщение и приостанавливаются, заменив маску сигналов процесса, блокирующую SIGCHLD, пустой маской. Это дает возможность появиться сигналу SIGCHLD, что в свою очередь вызывает запуск обработчика сигнала. Вот что происходит:

$ ch10-reap1 /* Запуск программы */

waiting for signal

Entered childhandler

  reaped process 23937

  reaped process 23938

  reaped process 23939

  reaped process 23940

  reaped process 23941

Exited childhandler

Обработчик сигнала собирает сведения о потомках за один проход.

Следующая программа, ch10-reap2.c, сходна с ch10-reap1.c. Разница в том, что она допускает появление сигнала SIGCHLD в любое время. Такое поведение увеличивает шанс получения более одного SIGCHLD, но не гарантирует это. В результате обработчик сигнала все равно должен быть готов обработать в цикле несколько потомков.

1  /* ch10-reap2.c — демонстрирует управление SIGCHLD, один сигнал на потомка */

2

   /* ...не изменившийся код пропущен... */

12

13 pid_t kids[MAX_KIDS];

14 size_t nkids = 0;

15 size_t kidsleft = 0; /* <<< Добавлено */

16

 /* ...не изменившийся код пропущен... */

41

42 /* childhandler --- перехват SIGCHLD, опрос всех доступных потомков */

43

44 void childhandler(int sig)

45 {

46  int status, ret;

47  int i;

48  char buf[100];

49  static const char entered[] = "Entered childhandler\n";

50  static const char exited[] = "Exited childhandler\n";

51

52  write(1, entered, strlen(entered));

53  for (i = 0; i < nkids; i++) {

54   if (kids[i] == NOT_USED)

55    continue;

56

57 retry:

58  if ((ret = waitpid(kids[i], &status, WNOHANG)) == kids[i]) {

59   strcpy(buf, "\treaped process ");

60   strcat(buf, format_num(ret));

61   strcat(buf, "\n");

62   write(1, buf, strlen(buf));

63   kids[i] = NOT_USED;

64   kidsleft--; /* <<< Добавлено */

65  } else if (ret == 0) {

    /* ...не изменившийся код пропущен... */

80  write(1, exited, strlen(exited));

81 }

Это идентично предыдущей версии за тем исключением, что у нас есть новая переменная, kidsleft, указывающая, сколько имеется не опрошенных потомков. Строки 15 и 64 помечают новый код.

83  /* main --- установка относящейся к порожденным процессам сведений

       и сигналов, создание порожденных процессов */

84

85  int main(int argc, char **argv)

86  {

     /* ...не изменившийся код пропущен... */

100

101  sigemptyset(&childset);

102  sigaddset(&childset, SIGCHLD);

103

104  /* sigprocmask(SIG_SETMASK, &childset, NULL); /* блокирование в коде main */

105

106  for (nkids = 0; nkids < 5; nkids++) {

107   if ((kids[nkids] = fork()) == 0) {

108    sleep(3);

109    _exit(0);

110   }

111   kidsleft++; /* <<< Added */

112  }

113

114  /* sleep(5); /* дать потомкам шанс завершиться */

115

116  while (kidsleft > 0) { /* <<< Добавлено */

117   printf("waiting for signals\n");

118   sigsuspend(&emptyset);

119  } /* <<< Добавлено */

120

121  return 0;

122 }

Здесь код также почти идентичен. Строки 104 и 114 закомментированы из предыдущей версии, а строки 111, 116 и 119 добавлены. Удивительно, при запуске поведение меняется в зависимости от версии ядра!

$ uname -a /* Отобразить версию системы */

Linux example1 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux

$ ch10-reap2 /* Запустить программу */

waiting for signals

Entered childhandler /* Опрос одного потомка */

  reaped process 2702

  pid 2703 not available yet

  pid 2704 not available yet

  pid 2705 not available yet

  pid 27 06 not available yet

Exited childhandler

waiting for signals

Entered childhandler /* И следующего */

  reaped process 2703

  pid 2704 not available yet

  pid 2705 not available yet

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler /* И так далее */

  reaped process 2704

  pid 2705 not available yet

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler

  reaped process 2705

  pid 2706 not available yet

Exited childhandler

waiting for signals

Entered childhandler

  reaped process 2706

Exited childhandler

В данном примере на каждый процесс поступает ровно один SIGCHLD! Хотя это прекрасно и полностью воспроизводимо на этой системе, это также необычно. Как на более раннем, так и на более позднем ядре и на Solaris программа получает один сигнал для более чем одного потомка:

$ uname -a /* Отобразить версию системы */

Linux example2 2.4.22-1.2115.npt1 #1 Wed Oct 29 15:42:51 EST 2003 i686 i686 i386 GNU/Linux

$ ch10-reap2 /* Запуск программы */

waiting for signals

Entered childhandler /* Обработчик сигнала вызван лишь однажды */

  reaped process 9564

  reaped process 9565

  reaped process 9566

  reaped process 9567

  reaped process 9568

Exited childhandler

ЗАМЕЧАНИЕ. В коде для ch10-reap2.c есть один важный дефект — состояние гонки. Взгляните еще раз на строки 106–112 в ch10-reap2.c. Что случится, если SIGCHLD появится при исполнении этого кода? Массив kids и переменные nkids и kidsleft могут оказаться разрушенными: код в main добавляет новый процесс, но обработчик сигнала вычитает один.

Этот пример кода является отличным примером критического раздела; он не должен прерываться при исполнении. Правильным способом работы с этим кодом является заключение его между вызовами, которые сначала блокируют, а затем разблокируют SIGCHLD.

10.8.3.3. Строгий родительский контроль

Структура siginfo_t и перехватчик сигнала с тремя аргументами дают возможность узнать, что случилось с потомком. Для SIGCHLD поле si_code структуры siginfo_t указывает причину посылки сигнала (остановка, возобновление, завершение порожденного процесса и т.д.). В табл. 10.5 представлен полный список значений. Все они определены в качестве расширения XSI стандарта POSIX.

Следующая программа, ch10-status.c, демонстрирует использование структуры siginfo_t.

1  /* ch10-status.c --- демонстрирует управление SIGCHLD, используя обработчик с 3 аргументами */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <signal.h>

6  #include <string.h>

7  #include <sys/types.h>

8  #include <sys/wait.h>

9

10 void manage(siginfo_t *si);

11

/* ...не изменившийся для format_num() код опущен... */


Таблица 10.5. Значения si_code XSI для SIGCHLD

Значение Смысл
CLD_CONTINUED Остановленный потомок был возобновлен.
CLD_DUMPED Потомок завершился с ошибкой, создан образ процесса
CLD_EXITED Потомок завершился нормально.
CLD_KILLED Потомок был завершен сигналом
CLD_STOPPED Порожденный процесс был остановлен.
CLD_TRAPPED Трассируемый потомок остановлен (Это условие возникает, когда программа трассируется — либо из отладчика, либо для мониторинга реального времени В любом случае, вы вряд ли увидите его в обычных ситуациях.)
Строки 3–8 включают стандартные заголовочные файлы, строка 10 объявляет manage(), которая имеет дело с изменениями состояния потомка, а функция format_num() не изменилась по сравнению с предыдущим.

37 /* childhandler --- перехват SIGCHLD, сбор данных лишь об одном потомке */

38

39 void childhandler(int sig, siginfo_t *si, void *context)

40 {

41  int status, ret;

42  int i;

43  char buf[100];

44  static const char entered[] = "Entered childhandler\n";

45  static const char exited[] = "Exited childhandler\n";

46

47  write(1, entered, strlen(entered));

48 retry:

49  if ((ret = waitpid(si->si_pid, &status, WNOHANG)) == si->si_pid) {

50   strcpy(buf, "\treaped process ");

51   strcat(buf, format_num(si->si_pid));

52   strcat(buf, "\n");

53   write(1, buf, strlen(buf));

54   manage(si); /* обработать то, что произошло */

55  } else if (ret > 0) {

56   strcpy(buf, "\treaped unexpected pid ");

57   strcat(buf, format_num(ret));

58   strcat(buf, "\n");

59   write(1, buf, strlen(buf));

60   goto retry; /* почему бы нет? */

61  } else if (ret == 0) {

62   strcpy(buf, "\tpid ");

63   strcat(buf, format_num(si->si_pid));

64   strcat(buf, " changed status\n");

65   write(1, buf, strlen(buf));

66   manage(si); /* обработать то, что произошло */

67  } else if (ret == -1 && errno == EINTR) {

68   write(1, "\tretrying\n", 10);

69   goto retry;

70  } else {

71   strcpy(buf, "\twaitpid() failed: ");

72   strcat(buf, strerror(errno));

73   strcat(buf, "\n");

74   write(1, buf, strlen(buf));

75  }

76

77  write(1, exited, strlen(exited));

78 }

Обработчик сигнала похож на показанные ранее. Обратите внимание на список аргументов (строка 39) и на то, что нет цикла.

Строки 49–54 обрабатывают завершение процесса, включая вызов manage() для вывода состояния.

Строки 55–60 обрабатывают случай неожиданного завершения потомка. Этого не должно происходить, поскольку обработчику сигнала передается специфическая для определенного порожденного процесса информация.

Строки 61–66 представляют для нас интерес: возвращаемое значение для изменений состояния равно 0. manage() имеет дело с деталями (строка 66).

Строки 67–69 обрабатывают прерывания, а строки 70–75 распоряжаются ошибками

80 /* child --- что сделать в порожденном процессе */

81

82 void child(void)

83 {

84  raise(SIGCONT); /* должен быть проигнорирован */

85  raise(SIGSTOP); /* заснуть, родитель снова разбудит */

86  printf("\t---> child restarted <---\n");

87  exit(42); /* нормальное завершение, дать возможность родителю получить значение */

88 }

Функция child() обрабатывает поведение порожденного процесса, предпринимая действия для уведомления родителя[113]. Строка 84 посылает SIGCONT, что может вызвать получение родителем события CLD_CONTINUED. Строка 85 посылает SIGSTOP, который останавливает процесс (сигнал не может быть перехвачен) и вызывает для родителя событие CLD_STOPPED. Когда родитель возобновляет порожденный процесс, последний выводит сообщение, что он снова активен, а затем завершается с известным статусом завершения.

90  /* main --- установка относящихся к порожденному процессу сведений

       и сигналов, создание порожденного процесса */

91

92  int main(int argc, char **argv)

93  {

94   pid_t kid;

95   struct sigaction sa;

96   sigset_t childset, emptyset;

97

98   sigemptyset(&emptyset);

99

100  sa.sa_flags = SA_SIGINFO;

101  sa.sa_sigaction = childhandler;

102  sigfillset(&sa.sa_mask); /* при вызове обработчика все заблокировать */

103  sigaction(SIGCHLD, &sa, NULL);

104

105  sigemptyset(&childset);

106  sigaddset(&childset, SIGCHLD);

107

108  sigprocmask(SIG_SETMASK, &childset, NULL); /* блокировать его в коде main */

109

110  if ((kid = fork()) == 0)

111   child();

112

113  /* здесь выполняется родитель */

114  for (;;) {

115   printf("waiting for signals\n");

116   sigsuspend(&emptyset);

117  }

118

119  return 0;

120 }

Программа main() все устанавливает. Строки 100–103 помещают на место обработчик. Строка 100 устанавливает флаг SA_SIGINFO таким образом, что используется обработчик с тремя аргументами. Строки 105–108 блокируют SIGCHLD.

Строка 110 создает порожденный процесс. Строки 113–117 продолжаются в родителе, используя для ожидания входящих сигналов sigsuspend().

123 /* manage --- разрешение различных событий, которые могут случиться с потомком */

124

125 void manage(siginfo_t *si)

126 {

127  char buf[100];

128

129  switch (si->si_code) {

130  case CLD_STOPPED:

131   write(1, "\tchild stopped, restarting\n", 27);

132   kill(si->si_pid, SIGCONT);

133   break;

134

135  case CLD_CONTINUED: /* not sent on Linux */

136   write(1, "\tchild continued\n", 17);

137   break;

138

139  case CLD_EXITED:

140   strcpy(buf, "\tchild exited with status ");

141   strcat(buf, format_num(si->si_status));

142   strcat(buf, "\n");

143   write(1, buf, strlen(buf));

144   exit(0); /* we're done */

145   break;

146

147  case CLD_DUMPED:

148   write(1, "\tchild dumped\n", 14);

149   break;

150

151  case CLD_KILLED:

152   write(1, " \tchild killed\n", 14);

153   break;

154

155  case CLD_TRAPPED:

156   write(1, "\tchild trapped\n", 15);

157   break;

158  }

159 }

Посредством функции manage() родитель обрабатывает изменение состояния в порожденном процессе, manage() вызывается, когда изменяется состояние и когда порожденный процесс завершился.

Строки 130–133 обрабатывают случай, когда потомок остановился; родитель возобновляет его, посылая SIGCONT.

Строки 135–137 выводят уведомление о возобновлении потомка. Это событие на системах GNU/Linux не происходит, и стандарт POSIX использует в этом случае невыразительный язык, просто говоря, что это событие может появиться, а не появится.

Строки 139–145 обрабатывают случай, когда порожденный процесс завершается, выводя статус завершения. Для этой программы родитель также все сделал, поэтому код завершается, хотя в более крупной программе это не то действие, которое должно быть сделано.

Другие случаи более специализированные. В случае события CLD_KILLED для получения дополнительных сведений было бы полезным значение status, заполненной функцией waitpid().

Вот что происходит при запуске:

$ ch10-status /* Запуск программы */

waiting for signals

Entered childhandler /* Вход в обработчик сигнала */

  pid 24279 changed status

  child stopped, restarting /* Обработчик действует */

Exited childhandler

waiting for signals

  ---> child restarted <--- /* Из потомка */

Entered childhandler

  reaped process 24279 /* Обработчик родителя опрашивает потомка */

  child exited with status 42

К сожалению, поскольку нет способа гарантировать доставку по одному SIGCHLD на каждый процесс, ваша программа должна быть готова восстановить несколько потомков за один проход.

10.9. Сигналы, передающиеся через fork() и exec()

Когда программа вызывает fork(), ситуация с сигналами в порожденном процессе почти идентична ситуации в родительском процессе. Установленные обработчики остаются на месте, заблокированные сигналы остаются заблокированными и т.д. Однако, любые ожидающие в родителе сигналы в потомке сбрасываются, включая установленный с помощью alarm() временной интервал. Это просто, и это имеет смысл.

Когда процесс вызывает одну из функций exec(), положение в новой программе следующее:

• Сигналы с установленным действием по умолчанию остаются с этим действием по умолчанию.

• Все перехваченные сигналы сбрасываются в состояние с действием по умолчанию.

• Сигналы, которые игнорируются, продолжают игнорироваться. Особым случаем является SIGCHLD. Если SIGCHLD до вызова exec() игнорировался, он может игнорироваться также и после вызова. В качестве альтернативы для него может быть восстановлено действие по умолчанию. То, что происходит на самом деле, стандартом POSIX намеренно не определяется. (Справочные страницы GNU/Linux не определяют, что делает Linux, и поскольку POSIX оставляет это не определенным, любой код, который вы пишете для использования SIGCHLD, должен быть подготовлен для обработки любого случая.)

• Сигналы, заблокированные до вызова exec(), остаются заблокированными и после вызова. Другими словами, новая программа наследует маску сигналов существующего процесса.

• Любые ожидающие сигналы (те, которые появились, но были заблокированы) сбрасываются. Новая программа не может их получить.

• Временной интервал, остающийся для alarm(), сохраняется на своем месте. (Другими словами, если процесс устанавливает alarm, а затем непосредственно вызывает exec(), новый образ в конечном счете получит SIGALARM. Если он сначала вызывает fork(), родитель сохраняет установки alarm, тогда как потомок, вызывающий exec(), не сохраняет.

ЗАМЕЧАНИЕ. Многие, если не все. программы предполагают, что сигналы инициализированы действиями по умолчанию и что заблокированных сигналов нет. Таким образом, особенно если не вы писали программу, запускаемую с помощью exec(), можно разблокировать перед вызовам exec() все сигналы

10.10. Резюме

«Наша история до настоящего времени, эпизод III»

- Арнольд Роббинс (Arnold Robbins) -
• Интерфейсы обработки сигналов развились от простых, но подверженных состояниям гонок, до сложных, но надежных. К сожалению, множественность интерфейсов затрудняет их изучение по сравнению с другими API Linux/Unix.

• У каждого сигнала есть связанное с ним действие. Действие может быть одним из следующих: игнорирование сигнала; выполнение действия системы по умолчанию или вызов предоставленного пользователем обработчика. Действие системы по умолчанию, в свою очередь, является одним из следующих: игнорирование сигнала, завершение процесса; завершение процесса с созданием его образа; остановка процесса или возобновление процесса, если он остановлен.

• signal() и raise() стандартизованы ISO С. signal() управляет действиями для определенных сигналов; raise() посылает сигнал текущему процессу. Остаются ли обработчики сигналов установленными после вызова или сбрасываются для действия по умолчанию, зависит от реализации, signal() и raise() являются простейшими интерфейсами, для многих приложений их достаточно.

• POSIX определяет функцию bsd_signal(), которая подобна signal(), но гарантирует, что обработчик остается установленным.

• Действия, происходящие после возвращения из обработчика, варьируют в зависимости от системы. Традиционные системы (V7, Solaris, возможно, и другие) восстанавливают действие сигнала по умолчанию. На этих системах прерванный системный вызов возвращает -1, устанавливая в errno значение EINTR. Системы BSD оставляют обработчик установленным и возвращают -1 с errno, содержащим EINTR, лишь в случае, когда не было перемещения данных; в противном случае, системный вызов запускается повторно.

• GNU/Linux придерживается POSIX, который похож, но не идентичен с BSD. Если не было перемещения данных, системный вызов возвращает -1/EINTR. В противном случае он возвращает объем перемещенных данных. Поведение BSD «всегда повторный запуск» доступно через интерфейсsigaction(), но он не является действием по умолчанию.

• Обработчики сигналов, используемые с signal(), подвержены состояниям гонок. Внутри обработчиков сигналов должны использоваться исключительно переменные типа volatile sig_atomic_t. (В целях упрощения в некоторых из наших примеров мы не всегда следовали этому правилу.) Таким же образом, для вызова из обработчика сигналов безопасными являются лишь функции из табл. 10.2.

• Первоначальной попыткой создания надежных сигналов был API сигналов System V Release 3 (скопированный из BSD 4.0). Не используйте его в новом коде.

• POSIX API содержит множество компонентов:

  • маску сигналов процесса, перечисляющую текущие заблокированные сигналы;

  • тип sigset_t для представления масок сигналов, и функции sigfillset(), sigemptyset(), sigaddset(), sigdelset() и sigismember() для работы с ними;

  • функцию sigprocmask() для установки и получения маски сигналов процесса,

  • функцию sigpending() для получения набора ожидающих сигналов;

  • API sigaction() и struct sigaction во всем их великолепии.

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

• Механизмами POSIX для посылки сигналов являются kill() и killpg(). Они отличаются от raise() в двух отношениях: (1) одни процесс может послать сигнал другому процессу или целой группе процессов (конечно, с проверкой прав доступа), и (2) посылка сигнала 0 ничего не посылает, но осуществляет проверку. Таким образом, эти функции предоставляют способ проверки наличия определенного процесса или группы процессов и возможность посылки ему (им) сигнала.

• Сигналы могут использоваться в качестве механизма IPC, хотя такой способ является плохим способом структурирования приложения, подверженным состояниям гонок. Если кто-то держит приставленным к вашей голове ружье, чтобы заставить вас работать таким способом, для правильной работы используйте тщательное блокирование сигналов и интерфейс sigaction().

• SIGALARM и системный вызов alarm() предоставляют низкоуровневый механизм для уведомления о прошествии определенного числа секунд, pause() приостанавливает процесс, пока не появятся какие-нибудь сигналы, sleep() использует их для помещения процесса в спящее состояние на заданный период времени: sleep() и alarm() не должны использоваться вместе. Сама pause() создает состояние гонки; вместо этого нужно использовать блокирование сигналов и sigsuspend().

• Сигналы управления заданиями реализуют управление заданиями для оболочки. Большую часть времени следует оставлять их с установленными действиями по умолчанию, но полезно понимать, что иногда имеет смысл их перехватывать.

• Перехват SIGCHLD позволяет родителю узнать, что делает порожденный им процесс. Использование 'signal(SIGCHLD, SIG_IGN)' (или sigaction() с SA_NOCLDWAIT) вообще игнорирует потомков. Использование sigaction() с SA_NOCLDSTOP предоставляет уведомления лишь о завершении. В последнем случае, независимо от того, заблокирован SIGCHLD или нет, обработчики сигналов для SIGCHLD должны быть готовы немедленно обработать несколько потомков. Наконец, использование sigaction() без SA_NOCLDSTOP с обработчиком сигналов с тремя аргументами дает вам причину получения сигнала.

• После fork() положение сигналов в порожденном процессе остается тем же самым, за исключением сброса ожидающих сигналов и установленных интервалов таймера. После exec() положение несколько более сложно — в сущности, все, что может быть оставлено, остается; для всего остального восстанавливаются значения по умолчанию.

Упражнения

1. Реализуйте bsd_signal() с использованием sigaction().

2. Если у вас не установлен GNU/Linux, запустите на своей системе ch10-catchint. Является ли ваша система традиционной или BSD?

3. Реализуйте функции System V Release 3 sighold(), sigrelse(), sigignore(), sigpause() и sigset(), использовав sigaction() и другие подходящие функции из POSIX API.

4. Потренируйте свои навыки в жонглировании битами. В предположении, что сигнал 0 отсутствует и что имеется не более 31 сигналов, предусмотрите typedef для sigset_t и напишите sigemptyset(), sigfillset(), sigaddset(), sigdelset() и sigismember().

5. Еще немного потренируйте свои навыки жонглирования битами. Повторите предыдущее упражнение, на этот раз предположив, что наибольшим сигналом является 42.

6. Теперь, когда вы сделали предыдущие два упражнения, найдите sigemptyset() и др. в своем заголовочном файле <signal.h>. (Может потребоваться поискать их; они могут быть в #include файлах, указанных в <signal.h>.) Являются ли они макросами или функциями?

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

8. Напишите свою собственную версию команды kill. Интерфейс должен быть таким:

kill [-s имя-сигнала] pid ...

Если сигнал не указан, программа должна посылать SIGTERM.

9. Как вы думаете, почему в современных оболочках, таких, как Bash и ksh93, kill является встроенной командой?

10. (Трудное) Реализуйте sleep(), используя alarm(), signal() и pause(). Что случится, если обработчик сигнала для SIGALRM уже установлен?

11. Поэкспериментируйте с ch10-reap.c, изменяя интервал времени, на который засыпает каждый потомок, и организуя достаточное число вызовов sigsuspend() для сбора сведений о всех потомках.

12. Попробуйте заставить ch10-reap2.c испортить информацию в kids, nkids и kidsleft. Теперь добавьте вокруг критического раздела блокирование/разблокирование и посмотрите, есть ли разница.

Глава 11 Права доступа и ID пользователей и групп

Linux, вслед за Unix, является многопользовательской системой. В отличие от большинства операционных систем для персональных компьютеров,[114] в которых имеется лишь один пользователь и в которых, кто бы ни находился перед компьютером, он имеет полный контроль, Linux и Unix различают файлы и процессы по владельцам и группам, которым они принадлежат. В данной главе мы исследуем проверку прав доступа и рассмотрим API для получения и установки идентификаторов владельцев и групп.

11.1. Проверка прав доступа

Как мы видели в разделе 5.4.2 «Получение информации о файлах», файловая система хранит идентификаторы владельца и группы файла в виде числовых значений; это типы uid_t и gid_t соответственно. Для краткости мы используем для «идентификатора владельца (пользователя)» и «идентификатора группы» сокращения UID и GID соответственно.

У каждого процесса есть несколько связанных с ним идентификаторов пользователя и группы. Для проверки прав доступа в качестве упрощения используется один определенный UID и GID; когда UID процесса совпадает с UID файла, биты прав доступа пользователя файла диктуют, что может сделать процесс с файлом. Если они не совпадают, система проверяет GID процесса с GID файла; при совпадении используются права доступа группы; в противном случае, используются права доступа для «остальных».

Помимо файлов, UID определяет, как один процесс может повлиять на другой путем посылки сигналов. Сигналы описаны в главе 10 «Сигналы».

Наконец, особым случаем является суперпользователь, root. root идентифицируется по UID, равным 0. Когда у процесса UID равен 0, ядро позволяет ему делать все, что он захочет: читать, записывать или удалять файлы, посылать сигналы произвольным процессам и т.д. (POSIX в этом отношении более непонятный, ссылаясь на процессы с «соответствующими привилегиями». Этот язык, в свою очередь, просочился в справочные страницы GNU/Linux и справочное руководство GLIBC online Info manual. Некоторые операционные системы действительно разделяют привилегии пользователей, и Linux также движется в этом направлении. Тем не менее, в настоящее время «соответствующие привилегии» означает просто процессы с UID, равным 0.)

11.1.1. Действительные и эффективные ID

Номера UID и GID подобны персональным удостоверениям личности. Иногда вам может понадобиться более одного удостоверяющего документа. Например, у вас могут быть водительские права или правительственное удостоверение личности[115]. Вдобавок, ваш университет или компания могли выдать вам свои удостоверения личности. То же самое относится и к процессам; они имеют при себе множество следующих номеров UID и GID:

Действительный ID пользователя

UID пользователя, породившего процесс.

Эффективный ID пользователя

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

Сохраненный set-user ID

Первоначальный эффективный UID при запуске программы (после выполнения exec.) Имеет значение при проверке прав доступа, когда процессу нужно менять действительный и эффективный UID в ходе работы. Эта концепция пришла из System V.

Действительный ID группы

GID пользователя, создавшего процесс, аналогично действительному UID.

Эффективный ID группы

GID, использующийся для проверки прав доступа, аналогично эффективному GID.

Сохраненный set-group ID

Первоначальный эффективный GID при запуске программы, аналогично сохраненному set-user ID.

Набор дополнительных групп

4.2 BSD ввело понятие набора групп. Помимо действительного и эффективного GID. у каждого процесса есть некоторый набор дополнительных групп, которым он принадлежит в одно и то же время. Таким образом, когда проверка прав доступа осуществляется для группы файла, ядро проверяет не только эффективный GID, но также и все GID в наборе групп.

Каждый процесс может получить все из этих значений. Обычный (не принадлежащий суперпользователю) процесс может переключать свои действительные и эффективные ID пользователя и группы. Процесс root (с эффективным UID, равным 0) может также устанавливать значения таким образом, как ему нужно (хотя это может оказаться односторонней операцией)

11.1.2. Биты Setuid и Setgid

Биты setuid и setgid[116] в правах доступа к файлу заставляют процесс принять эффективный UID или GID, который отличается от действительного. Эти биты накладываются на файл вручную с помощью команды chmod:

$ chmod u+s myprogram /* Добавить бит setuid */

$ chmod g+s myprogram /* Добавить бит setgid */

$ ls -l myprogram

-rwsr-sr-x 1 arnold devel 4573 Oct 9 18:17 myprogram

Наличие символа s в месте, где обычно находится символ x, указывает на присутствие битов setuid/setgid.

Как упоминалось в разделе 8.2.1 «Использование опций монтирования», опция nosuid команды mount для файловой системы предотвращает обращение ядра к битам setuid и setgid. Это мера безопасности; например, пользователь с домашней системой GNU/Linux мог бы вручную изготовить гибкий диск с копией исполняемого файла оболочки с setuid, устанавливающей в root. Но если система GNU/Linux в офисе или лаборатории монтирует файловые системы с гибкими дисками с опцией nosuid, запуск этой оболочки не предоставит доступа с правами root[117].

Каноническим (и возможно, злоупотребляемым) примером программы с setuid является игровая программа. Представьте, что вы написали по-настоящему крутую игру и хотите позволить пользователям системы играть в нее. Игра содержит файл счета, в котором перечислены высшие достижения.

Если вы не являетесь системным администратором, вы не можете создать отдельную группу только для тех пользователей, которым разрешено играть в игру и тем самым записывать в файл счета. Но если вы сделаете файл доступным для записи любому, чтобы каждый смог поиграть в игру, тогда каждый сможет также сжульничать и поместить наверх любое имя.

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

Та же логика применяется к программам setgid, хотя на практике программы с setgid используются гораздо реже, чем с setuid (Это также плохо; многие вещи, которые делаются программами с setuid root, легко могут быть сделаны программами с setgid или программами, которые вместо этого устанавливают setuid на обычного пользователя[118]).

11.2. Получение ID пользователя и группы

Получение от системы сведений о UID и GID просто. Функции следующие:

#include <unistd.h> /* POSIX */


uid_t getuid(void); /* Действительный и эффективный UID */

uid_t geteuid(void);

gid_t getgid(void); /* Действительный и эффективный GID */

gid_t getegid(void);

int getgroups(int size, gid_t list[]); /* Список дополнительных групп*/

Функции:

uid_t getuid(void)

Возвращает действительный UID.

uid_t geteuid(void)

Возвращает эффективный UID.

gid_t getgid(void)

Возвращает действительный GID.

gid_t getegid(void)

Возвращает эффективный GID.

int getgroups(int size, gid_t list[])

Заполняет до size элементов массива list из набора дополнительных групп процесса. Возвращаемое значение является числом заполненных элементов или -1 при ошибке. Включается ли в набор также эффективный GID, зависит от реализации. На системах, совместимых с POSIX, можно передать в size нулевое значение; в этом случае getgroups() возвращает число групп в наборе групп процесса. Затем можно использовать это значение для динамического выделения массива достаточного размера. На не-POSIX системах константа NGROUPS_MAX определяет максимально допустимый размер для массива list. Эту константу можно найти в современных системах в <limits.h>, а в старых системах в <sys/param.h>. Вскоре мы представим пример.

Возможно, вы заметили, что для получения сохраненных значений set-user ID или set-group ID нет вызовов. Это просто первоначальные значения эффективных UID и GID. Таким образом, для получения шести значений в начале программы вы можете использовать код наподобие этого:

uid_t ruid, euid, saved_uid;

gid_t rgid, egid, saved_gid;


int main(int argc, char **argv) {

 ruid = getuid();

 euid = saved_uid = geteuid();

 rgid = getgid();

 egid = saved_gid = getegid();

 /* ...оставшаяся программа... */

}

Вот пример получения набора групп. В качестве расширения gawk предоставляет доступ на уровне awk к значениям действительных и эффективных UID и GID и дополнительному набору групп. Для этого он должен получить набор групп. Следующая функция из main.c в дистрибутиве gawk 3.1.3:

1080 /* init_groupset --- инициализация набора групп */

1081

1082 static void

1083 init_groupset()

1084 {

1085 #if defined(HAVE_GETGROUPS) && defined(NGROUPS_MAX) && NGROUPS_MAX > 0

1086 #ifdef GETGROUPS_NOT_STANDARD

1087  /* Для систем, которые не отвечают стандарту, используйте старый способ */

1088  ngroups = NGROUPS_MAX;

1089 #else

1090  /*

1091   * Если оба аргумента при вызове равны 0, возвращаемое

1092   * значение является общим числом групп.

1093   */

1094  ngroups = getgroups(0, NULL);

1095 #endif

1096  if (ngroups == -1)

1097   fatal(_("could not find groups: %s"), strerror(errno));

1098  else if (ngroups == 0)

1099   return;

1100

1101  /* заполнить группы */

1102  emalloc(groupset, GETGROUPS_T*, ngroups * sizeof(GETGROUPS_T), "init_groupset");

1103

1104  ngroups = getgroups(ngroups, groupset);

1105  if (ngroups == -1)

1106   fatal(_("could not find groups: %s"), strerror(errno));

1107 #endif

1108 }

Переменные ngroups и groupset глобальные; их объявления не показаны. Макрос GETGROUPS_T (строка 1102) является типом для использования со вторым аргументом: на системе POSIX это gid_t, в противном случае int.

Строки 1085 и 1107 заключают в скобки все тело функции; на древних системах, в которых вообще нет наборов групп, тело функции пустое.

Строки 1086–1088 обрабатывают не-POSIX системы; до компиляции программы механизмом конфигурации определяется GETGROUPS_NOT_STANDARD. В этом случае код использует NGROUPS_MAX, как описано выше. (Даже а 2004 г. такие системы все еще существуют и используются; хотя, слава богу, число их уменьшается.)

Строки 1089–1094 для систем POSIX, причем нулевой параметр size используется для получения числа групп.

Строки 1096–1099 осуществляют проверку ошибок. Если возвращаемое значение 0, дополнительных групп нет, поэтому init_groupset() просто сразу возвращается.

Наконец, строка 1102 для выделения массива достаточного размера использует malloc() (посредством проверяющего ошибки макроса-оболочки, см. раздел 3.2.1.8 «Пример: чтение строк произвольной длины»). Затем строка 1104 заполняет этот массив.

11.3. Проверка для действительного пользователя: access()

В большинстве случаев значения эффективного и действительного UID и GID являются одними и теми же. Таким образом, не имеет значения, что проверка прав доступа к файлу осуществляется по эффективному ID, а не по действительному.

Однако, при написании приложения с setuid или setgid вы можете иногда захотеть проверить, является ли операция, разрешенная для эффективных UID и GID, также разрешенной для действительных UID и GID. В этом заключается задача функции access():

#include <unistd.h> /* POSIX */


int access(const char *path, int amode);

Аргумент path является путем к файлу для проверки действительных UID и GID. amode содержит объединение побитовым ИЛИ одного или нескольких из следующих значений:

R_OK  Действительный UID/GID разрешает чтение файла.

W_OK  Действительный UID/GID разрешает запись в файл.

X_OK  Действительный UID/GID разрешает исполнение файла или, в случае каталога, поиск в каталоге.

F_OK  Проверка существования файла.

Проверяется каждый компонент в имени пути, а на некоторых реализациях при проверке для root access() может действовать, как если бы был установлен X_OK, даже если в правах доступа к файлу не установлены биты, разрешающие исполнение. (Странно, но верно: в этом случае предупрежденный вооружен.) В Linux нет такой проблемы.

Если path является символической ссылкой, access() проверяет файл, на который указывает символическая ссылка.

Возвращаемое значение равно 0, если операция для действительных UID и GID разрешена, и -1 в противном случае. Соответственно, если access() возвращает -1, программа с setuid может запретить доступ к файлу, с которым в противном случае эффективный UID/GID смог бы работать:

if (access("/some/special/file", R_OK|W_OK) < 0) {

 fprintf(stderr, "Sorry: /some/special/file: %s\n",

  strerror(errno));

 exit(1);

}

По крайней мере для серии ядра Linux 2.4, когда тест X_OK применяется к файловой системе, смонтированной с опцией noexec (см. раздел 8.2.1 «Использование опций монтирования»), тест успешно проходится, если права доступа к файлу имеют разрешение на исполнение. Это верно, несмотря на то, что попытка выполнить файл завершилась бы неудачей.

ЗАМЕЧАНИЕ. Хотя использование access() перед открытием файла является обычной практикой, существует состояние гонки открываемый файл может быть сброшен при подкачке между проверкой функцией access() и вызовом open(). Необходимо осмотрительное программирование, такое, как проверка владельца и прав доступа с помощью stat() и fstat() до и после вызовов access() и open().

Например, программа pathchk проверяет действительность имен путей. GNU версия использует access() для проверки того, что компоненты каталога данного пути действительны. Из Coreutils pathchk.c:

244 /* Возвращает 1, если PATH является годным к использованию

245    каталогом, 0 если нет, 2 если он не существует. */

246

247 static int

248 dir_ok(const char *path)

249 {

250  struct stat stats;

251

252  if (stat (path, &stats)) /* Nonzero return = failure */

253   return 2;

254

255  if (!S_ISDIR(stats.st_mode))

256  {

257   error(0, 0, _("'%s" is not a directory"), path);

258   return 0;

259  }

260

261  /* Используйте access для проверки прав доступа на поиск,

262     поскольку при проверке битов прав доступа st_mode они могут

263     потеряться новыми механизмами управления доступом. Конечно,

264     доступ теряется, если вы используете setuid. */

265  if (access (path, X_OK) != 0)

266  {

267   if (errno == EACCES)

268    error (0, 0, _("directory '%s' is not searchable"), path);

269   else

270    error(0, errno, "%s", path);

271   return 0;

272  }

273

274  return 1;

275 }

Код прост. Строки 252–253 проверяют, существует ли файл. Если stat() завершится неудачей, файл не существует. Строки 255–259 удостоверяют, что файл в самом деле является каталогом.

Комментарий в строках 261–264 объясняет использование access(). Проверки битов st_mode недостаточно: файл может находиться в файловой системе, которая смонтирована только для чтения, в удаленной файловой системе или в файловой системе, не принадлежащей Linux или Unix, или у файла могут быть атрибуты, предотвращающие доступ. Таким образом, лишь ядро может в действительности сказать, будет ли работать access. Строки 265–272 осуществляют проверку, выдавая сообщение об ошибке, определяемое значением errno (строки 267–270).

11.4. Проверка для эффективного пользователя: euidaccess() (GLIBC)

GLIBC предоставляет дополнительную функцию, которая работает подобно access(), но проверяет в соответствии с эффективными UID, GID и набором групп:

#include <unistd.h> /* CLIBC */


int euidaccess(const char *path, int amode);

Аргументы и возвращаемое значение имеют тот же смысл, как для access(). Когда равны эффективный и действительный UID и эффективный и действительный GID, euidaccess() вызывает для осуществления теста access(). Это имеет то преимущество, что ядро может проверить файловую систему только для чтения или другие условия, которые не отражаются в правах доступа и владении файлами.

В противном случае euidaccess() сравнивает значения владельца и группы файла со значениями эффективных UID и GID и набора групп, используя соответствующие биты прав доступа. Этот тест основан на сведениях о файле от stat().

Если вы пишете переносимую программу, но предпочитаете использовать этот интерфейс, достаточно просто извлечь исходный файл из архива GLIBC и приспособить его для общего использования.

11.5. Установка дополнительных битов доступа для каталогов

На современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.

11.5.1. Группа по умолчанию для новых файлов и каталогов

В оригинальной системе Unix, когда open() или creat() создавали новый файл, он получал эффективные UID и GID создавшего их процесса.

V7, BSD вплоть до BSD 4.1 и System V вплоть до Release 3 все трактовали каталоги как файлы. Однако, с добавлением дополнительного набора групп в BSD 4.2 способ создания новых каталогов изменился: новые каталоги наследовали группу родительского каталога. Более того, новые файлы также наследовали ID группы родительского каталога, а не эффективный GID создающего процесса.

Идея, лежащая в основе множества групп и каталогов, которые работают таким способом, была в усилении группового взаимодействия. У каждого проекта организации, использующего систему, была бы отдельная назначенная ему группа. Для каждой такой группы в группе этого проекта был бы каталог верхнего уровня, и все файлы проекта имели бы доступ на чтение и запись (а при необходимости и на исполнение). Вдобавок, новые файлы автоматически получают группу родительского каталога. Состоя одновременно в нескольких группах (наборе групп), пользователь мог бы как угодно перемещаться между проектами с помощью простой команды cd, а все файлы и каталоги сохраняли бы свою надлежащую группу.

Что происходит на современных системах? Ну, это еще один из немногих случаев, когда можно поймать двух зайцев. SunOS 4.0 придумал механизм, который был включен в System V Release 4; сегодня он используется по крайней мере в Solaris и GNU/Linux. Эти системы придают биту setgid родительского каталога нового файла или каталога следующее значение:

Бит setgid родительского каталога сброшен

Новые файлы и каталоги получают эффективный GID создающего процесса.

Бит setgid родительского каталога установлен

Новые файлы и каталоги получают GID родительского каталога. Новые каталоги наследуют также установленный бит setgid.

(До SunOS 4.0 бит setgid для каталогов не имел определенного значения.) Следующий сеанс показывает бит setgid в действии:

$ cd /tmp /* Перейти в /tmp */

$ ls -ld . /* Проверить его права доступа */

drwxrwxrwt 8 root root 4096 Oct 16 17:40 .

$ id /* Отметить текущие группы */

uid=2076(arnold) gid=42(devel) groups=19(floppy),42(devel),2076(arnold)

$ mkdir d1 ; ls -ld d1 /* Создать новый каталог */

drwxr-xr-x 2 arnold devel 4096 Oct 16 17:40 d1 /* Эффективный ID группы

                                                  наследуется */

$ chgrp arnold d1 /* Сменить группу */

$ chmod g+s d1 /* Добавить бит setgid */

$ ls -ld d1 /* Проверить изменение */

drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:40 d1

$ cd d1 /* Перейти в него */

$ echo this should have group arnold on it > f1 /* создать новый файл */

$ ls -l f1 /* Проверить права доступа */

-rw-r--r-- 1 arnold arnold 36 Oct 16 17:41 f1

 /* Унаследовано от родителя */

$ mkdir d2 /* Создать каталог */

$ ls -ld d2 /* Проверить права доступа */

drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:51 d2

 /* Группа и setgid унаследованы */

Файловые системы ext2 и ext3 для GNU/Linux работают указанным способом. Вдобавок они поддерживают специальные опции монтирования grpid и bsdgroups, которые делают «использование группы родительского каталога» семантикой по умолчанию. (Два имени означают одно и то же.) Другими словами, когда используются эти опции монтирования, в родительских каталогах не нужно устанавливать свои биты seigid.

Противоположными опциями монтирования являются nogrpid и sysvgroups. Это поведение по умолчанию; однако, бит setgid. если он есть, все равно учитывается. (Здесь также оба имени означают одно и то же.)

POSIX устанавливает, что новые файлы и каталоги наследуют либо эффективный GID создающего процесса, либо группу родительского каталога. Однако, реализации должны предусмотреть способ заставить новые каталоги наследовать группу родительского каталога. Более того, стандарт рекомендует, чтобы приложения не полагались на то или иное поведение, но в случаях, когда это имеет значение, использовали chown() для принудительного назначения желательного GID для группы нового файла или каталога.

11.5.2. Каталоги и «липкий» бит

«Шерман, установите машину времени для 1976 г.»

- М-р Пибоди (Mr. Peabody) -
«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами[119]. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.

Таким образом, даже если программа в настоящее время не использовалась, предполагалось, что она вскоре могла быть использована другим пользователем, поэтому она могла быть быстро загружена.

В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.

Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или root. Вот пример:

$ ls -ld /tmp /* Показать права доступа к /tmp */

drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp

$ cd /tmp /* Перейти туда */

$ echo this is my file > arnolds-file /* Создать файл */

$ ls -l arnolds-file /* Показать его права доступа */

-rw-r--r-- 1 arnold devel 16 Oct 20 14:14 arnolds-file

$ su - miriam /* Смена пользователя */

Password:

$ cd /tmp /* Перейти в /tmp */

$ rm arnolds-file /* Попытка удаления файла */

rm: remove write-protected regular file 'arnolds-file'? y

 /* rm предупреждает */

rm: cannot remove 'arnolds-file': Operation not permitted

 /* Ядро запрещает удаление */

Основным назначением этой особенности является как раз использование в таких каталогах, как /tmp, куда хотят помещать свои файлы множество пользователей. С одной стороны, каталог должен иметь права записи для всех, чтобы каждый мог создавать там свои файлы. С другой стороны, раз запись разрешена для всех, любой пользователь может удалять файлы всех остальных пользователей! «Липкий» бит каталога красиво решает эту проблему. Для добавления к файлу или каталогу «липкого» бита используйте 'chmod +t':

$ mkdir mytmp /* Создать каталог */

$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */

$ ls -ld mytmp /* Проверить результат */

drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmp

В заключение, обратите внимание, что владелец каталога также может удалить файлы, даже если они не принадлежат ему.

11.6. Установка действительных и эффективных ID

Все становится интереснее, когда процессу приходится менять значения UID и GID. Установка набора групп проста. Изменение значений действительных и эффективных UID и GID сложнее.

11.6.1. Изменение набора групп

Функция setgroups() устанавливает новый набор групп:

#include <sys/types.h> /* Common */

#include <unistd.h>

#include <grp.h>


int setgroups(size_t size, const gid_t *list);

Параметр size указывает, сколько элементов в массиве list. Возвращаемое значение равно 0, если все было нормально, и -1 с установленным errno в противном случае.

В отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как root. Это один пример того, что POSIX называет привилегированной операцией; сама она как таковая не стандартизуется POSIX.

setgroups() используется любой программой, которая осуществляет регистрацию в системе, такой как /bin/login для регистрации в консоли и /bin/sshd для удаленной регистрации с помощью ssh.

11.6.2. Изменение действительного и эффективного ID

Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи — работая с действительным UID.

Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор ed: набор командной строки, начинающейся с '!', запускает оставшуюся часть строки в качестве команды оболочки. Набрав '!sh', вы получаете интерактивную оболочку. (Это работает до сих пор — попробуйте!) Предположим, описанная ранее гипотетическая игровая программа также предоставляет переход в оболочку: она должна быть запущена от имени действительного пользователя, а не эффективного. В противном случае, редактирование файла счета или многие гораздо худшие вещи становятся для игрока тривиальной задачей!

Таким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)

Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:

#include <sys/types.h> /* POSIX */

#include <unistd.h>


int seteuid(uid_t euid); /* Установка эффективного ID */

int setegid(gid_t egid);


int setuid(uid_t uid);

 /* Установка эффективного ID, root устанавливает все */

int setgid(gid_t gid);


int setreuid(uid_t ruid, uid_t euid);

 /* Совместимость с BSD, устанавливаются оба */

int setregid(gid_t rgid, gid_t egid);

Есть три набора функций. Первые два были созданы POSIX:

int seteuid(uid_t euid)

Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не root) может установить в качестве ID лишь в значения действительного, эффективного или сохраненного set-user ID. Приложения, которые будут переключать эффективный UID. должны использовать исключительно эту функцию.

Процесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова seteuid().

int setegid(gid_t egid)

Эта функция делает для эффективного ID группы то, что seteuid() делает для эффективного ID пользователя.

Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID:

int setuid(uid_t uid)

Для обычного пользователя эта функция также устанавливает лишь эффективный UID. Как и для seteuid(), значением эффективного UID может быть любое из текущих значений действительного, эффективного иди сохраненного set-user ID. Изменение не постоянно; эффективный UID может быть изменен последующим вызовом на другое значение (из того же исходного набора).

Однако, для root эта функция устанавливает в данное значение все три значения для действительного, эффективного и сохраненного set-user ID. Более того, изменение постоянно; прежнее ID нельзя восстановить. (Это имеет смысл: раз изменился сохраненный set-user ID, нет другого ID для восстановления.)

int setgid(gid_t gid)

Эта функция делает для эффективного ID группы то же, что setuid() делает для эффективного ID пользователя. Используется то же разграничение между обычными пользователями и root.

ЗАМЕЧАНИЕ. Возможность изменения ID группы зависит от эффективного ID пользователя. Эффективный GID, равный 0, не имеет особых привилегий.

Наконец, POSIX представляет для исторической совместимости две функции из BSD 4.2. В новом коде их лучше не использовать. Однако, поскольку вы, вероятно, увидите использующий эти функции старый код, мы их здесь опишем.

int setreuid(uid_t ruid, uid_t euid)

Устанавливает данные значения в качестве действительного и эффективного UID. Значение -1 для ruid или euid оставляет соответствующие ID без изменения. (Это похоже на chown(); см. раздел 5.5.1 «Смена владельца файла: chown(), fchown() и lchown()».)

root может устанавливать в качестве действительного и эффективного ID любое значение. В соответствии с POSIX пользователи, не являющиеся root, могут изменять лишь эффективный ID; то, что случится, если обычный пользователь попытается изменить действительный UID, «не определено». Однако, справочная страница GNU/Linux setreuid(2) разъясняет поведение Linux, в качестве действительного UID может быть установлено значение действительного или эффективного UID, а в качестве эффективного UID может быть значение действительного, эффективного или сохраненного set-user ID. (Для других систем см. справочную страницу setreuid(2).)

int setregid(gid_t rgid, gid_t egid)

Делает для действительных и эффективных ID групп то же, что setreuid() делает для действительных и эффективных ID пользователя. Используется то же разграничение между обычными пользователями и root.

Сохраненный set-user ID в модели BSD не существует, поэтому лежащей в основе setreuid() и setregid() идеей было упростить переключение между действительным и эффективным ID:

setreuid(geteuid(), getuid()); /* обмен действительным и эффективным */

Однако, с принятием POSIX модели сохранения set-user ID и функций seteuid() и setegid() функции BSD не следует использовать в новом коде. Даже документация BSD 4.4 помечает эти функции как устаревшие, рекомендуя вместо них seteuid()/setuid() и setegid()/setgid().

11.6.3. Использование битов setuid и setgid

Есть важные случаи, в которых действующая как root программа должна безвозвратно изменить все три значения действительного, эффективного и сохраненного set-user ID на ID обычного пользователя. Наиболее очевидным случаем является программа login, которую вы используете (либо непосредственно, либо удаленно) каждый раз при регистрации в системе GNU/Linux или Unix. Имеется иерархия программ, как очерчено на рис. 11.1.

Рис. 11.1. От init через getty через login к shell

Код для login слишком сложен, чтобы показать здесь, поскольку он имеет дело с рядом задач, не имеющих отношения к текущему обсуждению. Но мы можем очертить шаги, которые происходят во время регистрации, следующим образом:

1. init является самым первым процессом. Его PID равен 1. Все другие процессы являются его потомками. Ядро вручную создает процесс 1 во время загрузки и запускает в нем init. Он действует с действительным и эффективным UID, равными нулю, т.е. как root.

2. init читает /etc/inittab, который, помимо прочих вещей, сообщает init о том, на каких устройствах он должен запустить процесс getty. Для каждого такого устройства (такого, как консоль, последовательные терминалы или виртуальные консоли в системе GNU/Linux) init порождает новый процесс. Этот новый процесс использует затем exec() для запуска getty (от «get tty» («получить tty», т.е. терминал)). На многих системах GNU/Linux эта команда называется mingetty. Программа открывает устройство, сбрасывает его состояние и выводит приглашение 'login:'.

3. По получении регистрационного имени getty выполняет login. Программа login ищет имя пользователя в файле паролей, запрашивает пароль и проверяет его. Если пароль подходит, процесс login продолжается.

4. login изменяет домашний каталог пользователя, устанавливает начальное окружение, а затем устанавливает начальный набор открытых файлов. Он закрывает дескрипторы файлов, открывает терминал и использует dup() для копирования дескрипторов файла терминала в 0, 1 и 2. Вот откуда происходят дескрипторы уже открытых файлов стандартного ввода, стандартного вывода и стандартной ошибки.

5. Затем login использует setgroups() для установки дополнительного набора групп, setgid() для установки значений действительного, эффективного и сохраненного set-group ID в соответствующее значение группы пользователя, и наконец, setuid() для установки всех трех значений действительного, эффективного и сохраненного set-user ID в соответствующие значения для регистрирующегося пользователя. Обратите внимание, что вызов setuid() должен быть последним для того, чтобы другие два вызова завершились успешно.

6. Наконец, login вызывает зарегистрированную оболочку пользователя. Оболочки в стиле Борна после этого читают файлы /etc/profile и $HOME/.profile, если они существуют. Затем оболочка выводит приглашение.

Обратите внимание, как один процесс меняет свою сущность от системного процесса до процесса пользователя.Каждый потомок init начинается как копия init. Используя exec(), тот же самый процесс выполняет различные задания. Вызвав setuid() для перехода от root к обычному пользователю, процесс в конечном счете поступает непосредственно для работы пользователя. Когда вы выходите из оболочки (посредством CTRL-D или exit), процесс попросту завершается. Затем init возобновляет цикл, порождая новый getty, который выводит новое приглашение 'login:'.

ЗАМЕЧАНИЕ. Открытые файлы остаются открытыми и доступными для использования, даже после изменения процессом своих UID или GID. Таким образом, программы с setuid должны заранее открыть все нужные файлы, изменить их ID на ID действительного пользователя и продолжить оставшуюся часть работы без дополнительных привилегий

В табл. 11.1 приведена сводка шести стандартных функций для манипулирования значениями UID и GID.


Таблица 11.1. Сводка API для установки действительных и эффективных ID[120]

Функция Устанавливает Постоянно Обычный пользователь Root
seteuid() E Нет Из R, E, S Любое
setegid() E Нет Из R, E, S Любое
setuid() Root: R,E,S Другие: E Root: да Другие: нет Из R, E Любое
setgid() Root: R,E,S Другие: E Root: да Другие: нет Из R, E Любое
setreuid() E, может установить R Нет Из R, E Любое
setregid() E, может установить R Нет Из R, E Любое

11.7. Работа со всеми тремя ID: getresuid() и setresuid() (Linux)

Linux предоставляет дополнительные системные вызовы, посредством которых вы можете непосредственно работать с действительными, эффективными и сохраненными ID пользователя и группы:

#include <sys/types.h> /* Linux */

#include <unistd.h>


int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);

int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);


int setresuid(uid_t ruid, uid_t euid, uid_t suid);

int setresgid(gid_t rgid, gid_t egid, gid_t sgid);

Функции следующие:

int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)

Получает значения действительного, эффективного и сохраненного set-user ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno указывает проблему.

int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)

Получает значения действительного, эффективного и сохраненного set-group ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno обозначает проблему.

int setresuid(uid_t ruid, uid_t euid, uid_t suid)

Устанавливает значения действительного, эффективного и сохраненного set-user ID соответственно. Когда значение параметра равно -1, соответствующий UID остается без изменения.

Когда процесс действует как root, параметрами могут быть любые произвольные значения. Однако, использование ненулевого значения для euid вызывает постоянную, безвозвратную утерю привилегии root). В противном случае параметры должны быть одним из значений действительного, эффективного или сохраненного set-user ID.

int setresgid(gid_t rgid, gid_t egid, gid_t sgid)

Устанавливает значения действительного, эффективного и сохраненного set-group ID соответственно. Когда значение параметра равно -1, соответствующий GID остается без изменений.

Эта функция аналогична setresuid().

Функции setresuid() и setresgid() особенно ценны, поскольку их семантика ясно определена. Программист точно знает, каким может быть результат их вызова.

Более того, вызовы являются операциями типа «все или ничего»: они либо полностью успешны в осуществлении нужного изменения, либо терпят полную неудачу, оставляя текущее состояние как есть. Это повышает надежность, поскольку, опять-таки можно быть точно уверенным в том, что случилось.

11.8. Пересечение минного поля безопасности: setuid root

Настоящие минные поля трудно, но не невозможно перейти. Однако, это не является чем-то, что можно сделать легко, без тренировки или опыта

Точно также написание программ, которые используют setuid root, является трудной задачей. Имеется много, очень много проблем, о которых нужно знать, и почти все может иметь неожиданные последствия в плане безопасности. Такая попытка должна предприниматься очень осторожно.

В частности, стоит специально изучить проблемы безопасности Linux/Unix и потратить время на обучение написанию программ setuid root. Если вы сразу нырнете в эту проблему, прочитав лишь эту книгу и ничего более, можно быть уверенным, что ваша система будет взломана, легко и сразу. Маловероятно, что вы или ваши клиенты будут довольны.

Вот несколько руководящих принципов:

• Как можно меньше действуйте в качестве root. Скупо используйте свои чрезвычайные полномочия, лишь тогда, когда это абсолютно необходимо

• Соответствующим образом проектируйте свою программу. Разделите программу на составные части таким образом, чтобы все операции root были выполнены заранее, а оставшаяся программа работала в качестве обычного пользователя.

• При изменении или сбрасывании привилегий используйте setresuid(), если она у вас есть. В противном случае используйте setreuid(), поскольку у этих функций самая чистая семантика. Используйте setuid(), лишь когда вы хотите сделать постоянное изменение.

• Переходите от root к обычному пользователю в соответствующем порядке: сначала установите набор групп и значения GID, затем значения UID. Будьте особенно осторожны с fork() и exec(); действительные и эффективные UID при их вызове не изменяются, если вы не измените их явным образом.

• Рассмотрите использование прав доступа setgid и особой группы для вашего приложения. Если это будет работать, это убережет вас от большой головной боли.

• Рассмотрите отказ от наследуемого окружения. Если вам нужно сохранить некоторые переменные окружения, сохраните как можно меньше. Убедитесь в предоставлении подходящих значений для переменных окружения PATH и IFS.

• Избегайте execlp() и execvp(), которые зависят от значения переменной окружения PATH (хотя это менее проблематично, если вы сами восстанавливаете PATH).

Это просто некоторые из множества тактик по пересечению опасной зоны, известной своими подвохами, минами-ловушками и фугасами. Ссылки на другие источники информации см. в следующем разделе.

11.9. Рекомендуемая литература

Безопасность Unix (а следовательно, и GNU/Linux) является темой, требующей знаний и опыта для того, чтобы справиться с ней должным образом. В Эпоху Интернета она стала лишь труднее, не проще.

1. Practical UNIX & Internet Security, 3rd edition, by Simson Garfinkel, Gene Spafford, and Alan Schwartz, O'Reilly & Associates, Sebastopol, CA, USA, 2003. ISBN: 0-596-00323-4.

Это стандартная книга по безопасности Unix.

2. Building Secure Software. How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw. Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.

Это хорошая книга по написанию безопасного программного обеспечения, она включает проблемы setuid. Предполагается, что вы знакомы с основными API Linux/Unix; к моменту прочтения данной книги вы должны быть готовы к ее прочтению.

3. "Setuid Demystified," by Hao Chen, David Wagner, and Drew Dean. Proceedings of the 11th USENIX Security Symposium, August 5–9, 2002 http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf.

Гарфинкель, Спаффорд и Шварц (Garfinkel, Spafford, Schwartz) рекомендуют прочтение этого материала «до того, как вы даже подумаете о написании кода, который пытается сохранять и восстанавливать привилегии». Мы всецело согласны с ними.

11.10. Резюме

• Использование значений ID пользователя и группы (UID и GID) для идентификации файлов и процессов — вот что превращает Linux и Unix в многопользовательские системы. Процессы имеют значения как действительных, так и эффективных UID и GID, а также набор дополнительных групп. Обычно именно эффективный UID определяет, как один процесс может повлиять на другой, и эффективные UID, GID и набор групп проверяются на соответствие с правами доступа к файлу. Пользователи с эффективным UID, равным нулю, известные как root или суперпользователи, могут делать все, что захотят; система не использует для такого пользователя проверку прав доступа.

• Концепции сохраненных set-user ID и set-group ID пришли из System V и были приняты POSIX с полной поддержкой в GNU/Linux. Наличие этих отдельных значений ID дает возможность легко и безошибочно переключать при необходимости действительные и эффективные UID (и GID).

• Программы setuid и setgid создают процессы, в которых действительные и эффективные ID различаются. Программы как таковые помечаются дополнительными битами прав доступа к файлу. Биты setuid и setgid должны быть добавлены к файлу после его создания.

• getuid() и geteuid() получают значения действительного и эффективного UID соответственно, a getgid() и getegid() получают значения действительного и эффективного GID соответственно, getgroups() получает набор дополнительных групп, а в среде POSIX может запросить у системы, сколько членов содержит набор групп.

• Функция access() осуществляет проверку прав доступа к файлу для действительного пользователя, давая возможность программе setuid проверить полномочия реального пользователя. Обратите внимание, что часто проверка возвращаемых stat() сведений может не представить полной картины при условии, что файл может находиться на не родной или сетевой файловой системе.

• Функция GLIBC euidaccess() сходна с access(), но осуществляет проверку на основе значений эффективных UID и GID.

• «Липкий» бит и бит setgid при использовании с каталогами привносят дополнительную семантику. Когда для каталога установлен бит setgid, новые файлы в этом каталоге наследуют группу этого каталога. Новые каталоги делают то же самое, они также автоматически наследуют установку бита setgid. Без установленного бита setgid новые файлы и каталоги получают эффективный GID создающего их процесса. «Липкий» бит, установленный для каталогов, в которые в других отношениях разрешена запись, ограничивает право на удаление файла владельцем файла, владельцем каталога и root.

• Набор групп изменяется с помощью setgroups(). Эта функция не стандартизована POSIX, но существует на всех современных системах Unix. Ее может использовать лишь root.

• Изменение UID и GID довольно сложно. Семантика различных системных вызовов с течением времени изменилась. Новые приложения, которые будут изменять лишь свои эффективные UID/GID, должны использовать seteuid() и setegid(). Приложения, не действующие от имени root, могут также устанавливать свои эффективные ID с помощью setuid() и setgid(). Вызовы setreuid() и setregid() от BSD были предназначены для обмена значениями UID и GID; их использование в новых программах не рекомендуется.

• Приложения, действующие как root, могут перманентно заменить значения действительного, эффективного и сохраненного ID с помощью setuid() и setgid(). Одним из таких примеров является login, которая должна превратиться из программы, выполняющейся как root в не непривилегированную зарегистрированную оболочку, выполняющуюся от имени обычного пользователя.

• Функции Linux setresuid() и setresgid() следует использовать всегда, когда они доступны, поскольку они обеспечивают самое чистое и наиболее надежное поведение

• Написание приложений setuid-root не является задачей для новичка. Если вам нужно сделать такую вещь, сначала специально изучите проблемы безопасности. Для этого можно воспользоваться приведенными выше превосходными источниками.

Упражнения

1. Напишите простую версию команды id. Ее назначением является отображение в стандартный вывод ID пользователя и группы с указанием имен групп. Когда эффективный и действительный ID различаются, выводятся оба. Например:

$ id

uid=2076(arnold) gid=42(devel) groups=19(floppy), 42(devel), 2076(arnold)

Ее использование:

id [ пользователь ]

id -G [ -nr ] [ пользователь ]

id -g [ -nr ] [ пользователь ]

id -u [ -nr ] [ пользователь ]

При указанном пользователе выводятся сведения об этом пользователе; в противном случае id выводит сведения о пользователе, вызвавшем программу. Опции следующие:

 -G  Выводит все значения групп в виде чисел, без имен.

 -n  Выводит лишь имена, без числовых значений. Применяется с значениями пользователя и группы.

 -g  Выводит лишь эффективный GID.

 -u  Выводит лишь эффективный UID.

2. Напишите простую программу с именем sume и установите setuid на себя. Она должна запрашивать пароль (см. getpass(3)), который в целях данного примера может быть жестко вшит в исходный код программы. Если лицо, запустившее программу, вводит пароль правильно, sume должна выполнить exec оболочки. Попросите другого пользователя помочь вам ее протестировать.

3. Как вы относитесь к тому, чтобы сделать sume доступной для ваших друзей? Для ваших приятелей студентов или сотрудников? Для каждого пользователя на вашей системе?

Глава 12 Общие библиотечные интерфейсы — часть 2

В главе 6, «Общие библиотечные интерфейсы — часть 1», был представлен первый набор API библиотеки общего пользования. В некотором смысле, эти API поддерживают работу с фундаментальными объектами, которыми управляют системы Linux и Unix: время дня, пользователи и группы для файлов, сортировка и поиск.

Данная глава более эклектична; функции API, рассмотренные здесь, не особо связаны друг с другом. Однако, все они полезны в повседневном программировании под Linux/Unix. Наше представление движется от простых, более общих функций API к более сложным и более специализированным.

12.1. Операторы проверки: assert()

Оператор проверки (assertion) является утверждением, которое вы делаете о состоянии своей программы в определенный момент времени ее исполнения. Использование операторов проверок для программирования было первоначально разработано Хоаром (C.A.R. Hoare)[121]. Общая идея является частью «верификации программы»: так же, как вы проектируете и разрабатываете программу, вы можете показать, что она правильна, делая тщательно аргументированные утверждения о проявлениях кода вашей программы. Часто такие утверждения делаются об инвариантах — фактах о состоянии программы, которые, как предполагается, остаются верными на протяжении исполнения куска программы.

Операторы проверки особенно полезны для описания двух разновидностей инвариантов: предусловий и постусловий: условий, которые должны быть истинными соответственно перед и после исполнения сегмента кода. Простым примером предусловий и постусловий является линейный поиск:

/* lsearch --- возвратить индекс с данным значением в массиве или -1,

   если не найдено */

int lsearch(int *array, size_t size, int value) {

 size_t i;

 /* предусловие: array != NULL */

 /* предусловие: size > 0 */

 for (i = 0; i < size; i++)

  if (array[i] == value)

   return i;

 /* постусловие: i == size */

 return -1;

}

Этот пример определяет условия, используя комментарии. Но не было бы лучше проверить условия с использованием кода? Это является задачей макроса assert():

#include <assert.h> /* ISO С */


void assert(/* скалярное выражение */);

Когда скалярное выражение ложно, макрос assert() выводит диагностическое сообщение и завершает программу (с помощью функции abort(); см. раздел 12.4 «Совершение самоубийства: abort()»). ch12-assert.c снова предоставляет функцию lsearch(), на этот раз с оператором проверки и функцией main():

1  /* ch12-assert.с --- демонстрация операторов проверки */

2

3  #include <stdio.h>

4  #include <assert.h>

5

6  /* lsearch --- возвращает индекс с данным значением в массиве или -1, если не найдено */

7

8  int lsearch(int *array, size_t size, int value)

9  {

10  size_t i;

11

12  assert(array != NULL);

13  assert(size > 0);

14  for (i = 0; i < size; i++)

15   if (array[i] == value)

16    return i;

17

18  assert(i == size);

19

20  return -1;

21 }

22

23 /* main --- проверить наши условия */

24

25 int main(void)

26 {

27 #define NELEMS 4

28  static int array[NELEMS] = { 1, 17, 42, 91 };

29  int index;

30

31  index = lsearch(array, NELEMS, 21);

32  assert(index == -1);

33

34  index = lsearch(array, NELEMS, 17);

35  assert(index == 1);

36

37  index = lsearch(NULL, NELEMS, 10); /* won't return */

38

39  printf("index = %d\n", index);

40

41  return 0;

42 }

После компиляции и запуска оператор проверки в строке 12 «выстреливает»:

$ ch12-assert /* Запуск программы */

ch12-assert: ch12-assert.c:12: lsearch: Assertion 'array != ((void *)0)' failed.

Aborted (core dumped)

Сообщение от assert() варьирует от системы к системе. Для GLIBC на GNU/Linux сообщение включает имя программы, имя файла с исходным кодом и номер строки, имя функции, а затем текст завершившегося неудачей условия. (В этом случае именованная константа NULL проявляется в виде своего макрорасширения '((void*)0)'.)

Сообщение 'Aborted (core dumped)' означает, что ch12-assert создала файл core; т.е. снимок адресного пространства процесса непосредственно перед его завершением.[122] Этот файл может быть использован впоследствии с отладчиком; см. раздел 15.3 «Основы GDB». Создание файла core является намеренным побочным результатом assert(); предполагается, что произошла решительная ошибка, и вы хотите исследовать процесс с помощью отладчика для ее определения.

Вы можете отменить оператор проверки, компилируя свою программу с помощью опции командной строки '-DNDEBUG'. Когда этот макрос определен до включения <assert.h>, макрос assert() расширяется в код, который ничего не делает. Например:

$ gcc -DNDEBUG=1 ch12-assert.c -о ch12-assert /* Компиляция с -DNDEBUG */

$ ch12-assert /* Запуск */

Segmentation fault (core dumped) /* Что случилось? */

Здесь мы получили настоящий дамп ядра! Мы знаем, что операторы проверки были запрещены; сообщения «failed assertion» нет. Что же случилось? Рассмотрите строку 15 lsearch() при вызове из строки 37 main(). В этом случае переменная array равна NULL. Доступ к памяти через указатель NULL является ошибкой. (Технически различные стандарты оставляют «неопределенным» то, что происходит при разыменовывании указателя NULL. Наиболее современные системы делают то же, что и GNU/Linux; они завершают процесс, посылая ему сигнал SIGSEGV; это, в свою очередь, создает дамп ядра. Этот процесс описан в главе 10 «Сигналы».

Этот случай поднимает важный момент относительно операторов проверки. Часто программисты ошибочно используют операторы проверки вместо проверки ошибок времени исполнения. В нашем случае тест 'array != NULL' должен был быть проверкой времени исполнения:

if (array == NULL) return -1;

Тест 'size > 0' (строка 13) менее проблематичен; если size равен 0 или меньше 0, цикл никогда не исполнится, и lsearch() (правильно) возвратит -1. (По правде, этот оператор проверки не нужен, поскольку код правильно обрабатывает случай 'size <= 0'.)

Логика, стоящая за отменой оператора проверки, заключается в том, что дополнительные проверки могут снизить производительность программы и поэтому должны быть запрещены в заключительной версии программы. Хоар[123], однако, сделал такое замечание:

«В конце концов, абсурдно делать тщательные проверки безопасности при отладочных запусках, когда к результатам нет никакого доверия, а затем удалять их из финальных версий, когда ошибочный результат может быть дорогим или катастрофическим. Что бы мы подумали об энтузиасте-мореплавателе, который надевает свой спасательный жилет при тренировке на сухой земле и снимает его, как только выходит в море?»

С такими мнениями, наша рекомендация заключается во внимательном использовании операторов проверки- во-первых, для любого данного оператора проверки рассмотрите возможность использования вместо него проверки времени исполнения. Во-вторых, тщательно разместите свой оператор проверки, чтобы не было возражений против их оставления на своем месте лаже в финальной версии вашей программы.

Наконец, отметим следующее из раздела «Ошибки» справочной страницы GNU/Linux assert(3):

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

Знаменитый принцип неопределенности Гейзенберга из физики указывает, что чем более точно вы определите скорость частицы, тем менее точно вы определите ее положение, и наоборот. В терминах непрофессионала это означает что простой факт наблюдения частицы влияет на нее.

Сходное явление совершается в программировании, не связанном с физикой частиц: действие компилирования программы для отладки или запуска ее а режиме отладки может изменить поведение программы. В частности, первоначальная ошибка может исчезнуть. Такие ошибки в разговоре называют гейзенберговскими.

Справочная страница предостерегает нас от использования при вызовах assert() выражений с побочными эффектами:

assert(*p++ == '\n');

Здесь побочным эффектом является увеличение указателя p как часть теста. Когда определен NDEBUG, аргумент выражения исчезает из исходного кода; он никогда не исполняется. Это может привести к неожиданной неудаче. Однако, как только при подготовке к отладке запрет на операторы проверки отменяется, все начинает снова работать! Такие проблемы трудно отследить.

12.2. Низкоуровневая память: функции memXXX()

Несколько функций предоставляют возможность для работы с произвольными блоками памяти низкоуровневые службы. Все их имена начинаются с префикса 'mem':

#include <string.h> /* ISO C */


void *memset(void *buf, int val, size_t count);

void *memcpy(void *dest, const void *src, size_t count);

void *memmove(void *dest, const void *src, size_t count);

void *memccpy(void *dest, const void *src, int val, size_t count);

int memcmp(const void *buf1, const void *buf2, size_t count);

void *memchr(const void *buf, int val, size_t count);

12.2.1. Заполнение памяти: memset()

Функция memset() копирует значение val (интерпретируемое как unsigned char) в первые count байтов буфера buf. Она особенно полезна для обнуления блоков динамической памяти:

void *p = malloc(count);

if (p != NULL)

 memset(p, 0, count);

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

12.2.2. Копирование памяти: memcpy(), memmove() и memccpy()

Три функции копируют один блок памяти в другой. Первые две функции отличаются в обработке перекрывающихся областей памяти; третья копирует память, но останавливается при встрече с определенным значением.

void *memcpy(void *dest, const void *src, size_t count)

Это простейшая функция. Она копирует count байтов из src в dest. Она не обрабатывает перекрывающиеся области памяти. Функция возвращает dest.

void *memmove(void *dest, const void *src, size_t count)

Подобно memcpy(), она также копирует count байтов из src в dest. Однако, она обрабатывает перекрывающиеся области памяти. Функция возвращает dest.

void *memccpy(void *dest, const void *src, int val, size_t count)

Эта копирует байты из src в dest, останавливаясь либо после копирования val в dest, либо после копирования count байтов. Если она находит val, то возвращает указатель на положение в dest сразу за val. В противном случае возвращается NULL.

Теперь, в чем проблема с перекрывающейся памятью? Рассмотрим рис. 12.1.

Рис. 12.1. Перекрывающиеся копии

Целью является скопировать четыре экземпляра struct xyz от data[0] до data[3] в участок от data[3] до data[6]. Здесь проблемой является data[3], побайтовое копирование с перемещением в памяти из data[0] затрет data[3] до того, как он будет безопасно скопирован в data[6]! (Может возникнуть также сценарий, когда копирование в памяти в обратном направлении разрушит перекрывающиеся данные.)

Функция memcpy() была первоначальной функцией в System V API для копирования блоков памяти; ее поведение для перекрывающихся блоков памяти не была подробно определена тем или иным способом. Для стандарта С 1989 г. комитет почувствовал, что это отсутствие определенности является проблемой, поэтому они придумали memmove(). Для обратной совместимости memcpy() была оставлена, причем поведение для перекрывающейся памяти было специально отмечено как неопределенное, а в качестве процедуры, корректно разрешающей проблемные случаи, была предложена memmove().

Какую из них использовать в своем коде? Для библиотечной функции, которая не знает, какие области памяти ей передаются, следует использовать memmove(). Таким способом вы гарантируете, что не будет проблем с перекрывающимися областями. Для кода приложения, который «знает», что две области не перекрываются, можно безопасно использовать memcpy().

Как для memcpy(), так и для memmove() (как и для strcpy()) буфер назначения является первым аргументом, а источник — вторым. Чтобы запомнить это, обратите внимание на порядок, который тот же самый, как в операторе присваивания:

dest = src;

(Справочные страницы во многих системах не помогают, предлагая прототип в виде 'void *memcpy(void *buf1, void *buf2, size_t n)' и полагаясь на то, что текст объяснит, что есть что. К счастью, справочная страница GNU/Linux использует более осмысленные имена.)

12.2.3. Сравнение блоков памяти: memcmp()

Функция memcmp() сравнивает count байтов из двух произвольных буферов данных. Возвращаемое ею значение подобно strcmp(): отрицательное, нулевое или положительное, если первый буфер меньше, равен или больше второго.

Вы можете поинтересоваться: «Почему бы не использовать для такого сравнения strcmp()?» Разница между двумя функциями в том, что memcmp() не принимает во внимание нулевые байты (завершающий строку '\0'.) Таким образом, memcmp() является функцией, которая используется, когда вам нужно сравнить произвольные двоичные данные.

Другим преимуществом memcmp() является то, что она быстрее типичной реализации на C:

/* memcmp --- пример реализации на С, НЕ для реального использования */

int memcmp(const void *buf1, const void *buf2, size_t count) {

 const unsigned char *cp1 = (const unsigned char*)buf1;

 const unsigned char *cp2 = (const unsigned char*)buf2;

 int diff;

 while (count-- != 0) {

  diff = *cp1++ - *cp2++;

  if (diff != 0)

   return diff;

 }

 return 0;

}

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

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

12.2.4. Поиск байта с данным значением: memchr()

Функция memchr() сходна с функцией strchr(): она возвращает местоположение определенного значения внутри произвольного буфера. Как и в случае memcmp() против strcmp(), основной причиной для использования memchr() является использование произвольных двоичных данных.

GNU wc использует memchr() при подсчете лишь строк и байтов[124], и это позволяет быть быстрой. Из wc.c в GNU Coreutils:

257  else if (!count_chars && !count_complicated)

258  {

259   /* Использует отдельный цикл при подсчете лишь строк или строк и байтов -

260      но не символов или слов. */

261  while ((bytes_read = safe_read(fd, buf, BUFFER_SIZE)) > 0)

262  {

263   register char *p = buf;

264

265   if (bytes_read == SAFE_READ_ERROR)

266   {

267    error(0, errno, "%s", file);

268    exit_status = 1;

269    break;

270   }

271

272   while ((p = memchr(p, '\n', (buf + bytes_read) - p)))

273   {

274    ++p;

275    ++lines;

276   }

277   bytes += bytes_read;

278  }

279 }

Внешний цикл (строки 261–278) читает блоки данных из входного файла. Внутренний цикл (строки 272–276) использует memchr() для поиска и подсчета символов конца строки. Сложное выражение '(buf + bytes_read) - р' сводится к числу оставшихся байтов между текущим значением p и концом буфера.

Комментарии в строках 259–260 нуждаются в некотором объяснении. Вкратце, современные системы могут использовать символы, занимающие более одного байта в памяти и на диске. (Это несколько более подробно обсуждается в разделе 13.4 «Не могли бы вы произнести это для меня по буквам?».) Таким образом, wc должна использовать другой код, если она различает байты и символы: этот код имеет дело со случаем подсчета байтов.

12.3. Временные файлы

Временный файл является в точности тем, что звучит в его названии: файл, в котором при исполнении программы хранятся данные, которые больше не нужны после завершения программы. sort читает со стандартного ввода, если в командной строке не указаны файлы или вы используете в качестве имени файла '-'. Тем не менее, sort должна прочесть все свои входные данные, прежде чем сможет вывести отсортированные результаты. (Подумайте об этом немного, и вы увидите, что это так.) Когда читается стандартный ввод, данные должны быть где-то сохранены, прежде чем sort сможет их отсортировать; это отличное применение для временного файла. sort использует временные файлы также для хранения промежуточных результатов сортировки.

Удивительно, но имеются пять различных функций для создания временных файлов. Три из них работают посредством создания строк, представляющих (предположительно) уникальные имена файлов. Как мы увидим, их обычней следует избегать. Оставшиеся две работают путем создания и открытия временного файла; эти функции предпочтительнее для использования.

12.3.1. Создание временных имен файлов (плохо)

Имеются три функции, назначением которых является создание имени уникального, не существующего файла. Получив такое имя, вы можете использовать его для создания временного файла. Поскольку имя уникально, вам «гарантируется» исключительное использование файла. Вот объявления функций:

#include <stdio.h>


char *tmpnam(char *s); /* ISO С */

char *tempnam(const char *dir, const char *pfx); /* XSI */

char *mktemp(char *template); /* ISO С */

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

char *tmpnam(char *s)

Генерирует уникальное имя файла. Если s не равен NULL, он должен быть размером по крайней мере L_tmpnam байтов, и в него копируется уникальное имя. Если s равен NULL, имя генерируется во внутреннем статическом буфере, который может быть переписан при последующих вызовах. Префикс каталогов в пути будет P_tmpdir. Как P_tmpdir, так и L_tmpnam определены в <stdio.h>.

char *tempnam(const char *dir, const char *pfx)

Подобно tmpnam() дает вам возможность указать префикс каталогов. Если dir равен NULL, используется P_tmpdir. Аргумент pfx, если он не равен NULL, определяет до пяти символов для использования в качестве начальных символов имени файла tempnam() выделяет память для имен файлов, которые она генерирует. Возвращенный указатель может впоследствии использоваться с free() (и это следует сделать, если хотите избежать утечек памяти).

char *mktemp(char *template)

Генерирует уникальные имена файлов на основе шаблона. Последними шестью символами template должны быть 'ХХХХХХ'; эти символы замещаются уникальным суффиксом.

ЗАМЕЧАНИЕ. Аргумент template функции mktemp() переписывается. Поэтому он не должен быть строковой константой. Многие компиляторы, предшествовавшие стандарту С, помещают строковые константы в сегмент данных вместе с обычными глобальными переменными. Хотя в исходном коде они определены как константы, их можно переписать, таким образом, нередко встречался такой код:

/* Код в старом стиле: не используйте его */

char *tfile = mktemp("/tmp/myprogXXXXXX");

/* ...использование файла... */

На современных системах такой код. вероятно, завершится неудачей, в наши дни строковые константы находятся в сегментах памяти только для чтения.

Использование этих функций довольно просто. Файл ch12-mktemp.c демонстрирует mktemp(); нетрудно изменить его для использования других функций:

1  /* ch12-mktemp.с --- демонстрирует простое использование mktemp().

2     Для краткости проверка ошибок опущена */

3

4  #include <stdio.h>

5  #include <fcntl.h> /* для флагов открытия */

6  #include <limits.h> /* для PATH_MAX */

7

8  int main(void)

9  {

10  static char template[] = "/tmp/myfileXXXXXX";

11  char fname[PATH_MAX];

12  static char mesg[] =

13   "Here's lookin' at you, kid'\n"; /* вместо "hello, world" */

14  int fd;

15

16  strcpy(fname, template);

17  mktemp(fname);

18

19  /* ОКНО СОСТОЯНИЯ ГОНКИ ОТКРЫВАЕТСЯ */

20

21  printf("Filename is %s\n", fname);

22

23  /* ОКНО СОСТОЯНИЯ ГОНКИ ТЯНЕТСЯ ДОСЮДА */

24

25  fd = open(fname, O_CREAT|O_RDWR|O_TRUNC, 0600);

26  write(fd, mesg, strlen(mesg));

27  close(fd);

28

29  /* unlink(fname); */

30

31  return 0;

32 }

Переменная template (строка 10) определяет шаблон имени файла; 'ХХХХХХ' будет заменен уникальным значением. Строка 16 копирует шаблон в fname, которая не является константой: ее можно изменить. Строка 18 вызывает mktemp() для генерирования имени файла, а строка 21 выводит ее, так, чтобы мы могли видеть, что это такое. (Вскоре мы объясним комментарии в строках 19 и 23.)

Строка 25 открывает файл, создавая его при необходимости. Строка 26 записывает сообщение в mesg, а строка 27 закрывает файл. В программе, в которой файл должен быть удален после завершения работы с ним, строка 29 была бы не закомментирована. (Иногда временный файл не следует удалять; например, если файл после полной записи будет переименован.) Мы закомментировали ее, чтобы можно было запустить эту программу и посмотреть на файл впоследствии. Вот что происходит при запуске программы:

$ ch12-mktemp /* Запуск программы */

Filename is /tmp/myfileQES4WA /* Вывод имени файла */

$ cat /tmp/myfileQES4WA

Here's lookin' at you, kid' /* Содержит то, что ожидалось */

$ ls -l /tmp/myfileQES4WA /* To же с владельцем и доступом */

-rw------- 1 arnold devel 28 Sep 18 09:27 /tmp/myfileQES4WA

$ rm /tmp/myfileQES4WA /* Удалить его */

$ ch12-mktemp / * Используется ли повторно то же имя? */

Filename is /tmp/myfileic7xCy /* Нет. Это хорошо */

$ cat /tmp/myfileic7xCy /* Снова проверить содержание */

Here's lookin' at you, kid!

$ ls -l /tmp/myfileic7xCy /* Снова проверить владельца и доступ */

-rw------- 1 arnold devel 28 Sep 18 09:28 /tmp/myfileic7xCy

Все кажется работающим замечательно, mktemp() возвращает уникальное имя, ch12-mktemp создает файл с нужными правами доступа, и содержание то самое, которое ожидалось. Так в чем же проблема со всеми этими функциями?

Исторически mktemp() использовала простой, предсказуемый алгоритм для создания замещающих символов для 'ХХХХХХ' в шаблоне. Более того, интервал между временем, когда генерируется имя файла, и временем, когда создается сам файл, создает состояние гонки.

Как? Ну, Linux и Unix являются системами с квантованием времени, методикой, которая разделяет время процессора между всеми исполняющимися процессами. Это означает, что, хотя программа кажется выполняющейся все время, в действительности есть моменты, когда процессы спят, т.е. ожидают выполнения на процессоре.

Теперь рассмотрите программу профессора для отслеживания оценок студентов. Как профессор, так и злоумышленный студент в одно и то же время используют сильно нагруженную многопользовательскую систему. Программа профессора использует для создания временных файлов mktemp(), видевший в прошлом, как оценивающая программа создает и удаляет временные файлы, выяснил алгоритм, который использует mktemp(). (В версии GLIBC нет этой проблемы, но не все системы используют GLIBC!) Рис 12.2 иллюстрирует состояние гонки и то, как студент его использует.

Рис. 12.2. Состояние гонки с mktemp()

Вот что случилось.

1. Оценивающая программа использует mktemp() для создания имени файла. По возвращении из mktemp() открыто окно состояния гонки (строка 19 в ch12-.mktemp.c).

2. Ядро останавливает оценивающую программу, чтобы могли поработать другие программы в системе. Это происходит до вызова open().

Пока оценивающая программа остановлена, студент создает файл с тем же самым именем, которое вернула mktemp(). (Помните, выяснить алгоритм было просто.) Студент создает файл с дополнительной ссылкой, так что когда оценивающая программа удаляет файл, он все еще будет доступен для прочтения.

3. Теперь оценивающая программа открывает файл и записывает в него данные. Студент создал файл с правами доступа -rw-rw-rw-, поэтому это не представляет проблему.

4. Когда оценивающая программа завершает работу, она удаляет временный файл. Однако, у студента все еще есть копия. Например, может быть возможность получения прибыли при заблаговременной продаже своим товарищам их оценок.

Наш пример упрощенный; помимо простого похищения данных с оценками умный (хотя и аморальный) студент мог бы вместо этого изменить данные. Если бы профессор не проверял результаты работы своей программы дважды, никто бы ничего не узнал.

ЗАМЕЧАНИЕ. Мы не рекомендуем делать что-либо из этого! Если вы студент, не пытайтесь сделать что-либо подобное. Первое и самое главное, это неэтично. Во-вторых, вас могут выгнать из школы. В-третьих, ваши профессора, наверное, не сталь наивны, чтобы использовать mktemp() в своих программах. Этот пример лишь для иллюстрации!

По приведенным и другим причинам, все три описанные в данном разделе функции не следует никогда использовать. Они существуют в POSIX и GLIBC лишь для поддержки старых программ, которые были написаны до того, как была осознана опасность этих процедур С этой целью системы GNU/Linux генерируют во время компоновки сообщение:

$ cc ch12-mktemp.c -о ch12-mktemp /* Компилировать программу */

/tmp/cc1XCvD9.о(.text+0x35): In function 'main':

: the use of 'mktemp' is dangerous, better use 'mkstemp'

(Мы рассмотрим mkstemp() в следующем подразделе.)

Если бы в вашей системе не было mkstemp(), подумайте, как вы могли бы использовать эти интерфейсы для ее эмулирования. (См. также «Упражнения» для главы 12 в конце.)

12.3.2. Создание и открывание временных файлов (хорошо)

Есть две функции, не имеющие проблем состояния гонки. Одна из них предназначена для использования с библиотекой <stdio.h>:

#include <stdio.h> /* ISO С */


FILE *tmpfile(void);

Другая функция для использования с системными вызовами на основе дескрипторов файлов:

#include <stdio.h> /* XSI */


int mkstemp(char* template);

tmpfile() возвращает значение FILE*, представляющее уникальный открытый временный файл. Файл открывается в режиме "w+b". w+ означает «открыть для чтения и записи, сначала урезав файл», a b означает двоичный, а не текстовый режим. (На системах GNU/Linux или Unix нет разницы, но на других системах есть.) Файл автоматически удаляется, когда закрывается указатель файла; нет способа получить имя файла, чтобы сохранить его содержимое. Программа в ch12-tmpfile.c демонстрирует tmpfile():

/* ch12-tmpfile.с --- демонстрация tmpfile().

   Проверка ошибок для краткости опущена */

#include <stdio.h>


int main(void) {

 static char mesg[] =

  "Here's lookin' at you, kid!"; /* заменяет "hello, world" */

 FILE *fp;

 char buf[BUFSIZ];


 fp = tmpfile();                 /* Получить временный файл */

 fprintf(fp, "%s",mesg);        /* Записать s него */

 fflush(fp);                     /* Сбросить на диск */

 rewind(fp);                     /* Перейти в начало */

 fgets(buf, sizeof buf, fp);     /* Прочесть содержимое */

 printf("Got back <%s>\n", buf); /* Вывести полученные данные */

 fclose(fp);                     /* Закрыть файл, закончить */

 return 0;                       /* Все сделано */

}

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

$ ch12-tmpfile

Got back <Here's lookin' at you, kid!>

Ранее мы видели, что авторы GLIBC рекомендуют использование функции mkstemp():

$ cc ch12-mktemp.с -о ch12-mktemp /* Компилировать программу */

/tmp/cc1XCvD9.о(.text+0x35): In function "main':

: the use of 'mktemp' is dangerous, better use 'mkstemp'

Эта функция похожа на mktemp() в том, что она принимает имя файла, оканчивающееся на 'ХХХХХХ', и заменяет эти символы уникальным суффиксом для создания уникального имени файла. Однако, она идет на один шаг дальше. Она создает и открывает файл. Файл создается с доступом 0600 (т.е. -rw-------). Таким образом, доступ к файлу может получить только пользователь, запустивший программу.

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

Возвращаемое значение является дескриптором открытого файла, который может использоваться для чтения и записи. Для удаления файла после завершения работы с ним должно использоваться имя пути, сохраненное теперь в переданном mkstemp() буферу. Все это демонстрируется в ch12-mkstemp.c, который является простой модификацией ch12-tmpfile.с:

/* ch12-mkstemp.с --- демонстрирует mkstemp().

   Проверка ошибок для краткости опущена */

#include <stdio.h>

#include <fcntl.h> /* для флагов открытия */

#include <limits.h> /* для PATH_МАХ */


int main(void) {

 static char template[] = "/tmp/myfileXXXXXX";

 char fname[PATH_MAX];

 static char mesg[] =

  "Here's lookin' at you, kid!\n"; /* заменяет "hello, world" */

 int fd;

 char buf[BUFSIZ];

 int n;


 strcpy(fname, template);           /* Копировать шаблон */

 fd = mkstemp(fname);               /* Создать и открыть временный файл */

 printf("Filename is %s\n", fname); /* Вывести его для сведений */

 write(fd, mesg, strlen(mesg));     /* Что-нибудь записать в файл */

 lseek(fd, 0L, SEEK_SET);           /* Перейти в начало */

 n = read(fd, buf, sizeof(buf));

  /* Снова прочесть данные; НЕ завышается '\0'! */

 printf("Got back: %.*s", n, buf);  /* Вывести его для проверки */

 close(fd);                         /* Закрыть файл */

 unlink(fname);                     /* Удалить его */

 return 0;

}

При запуске получаем ожидавшиеся результаты:

$ ch12-mkstemp

Filename is /tmp/myfileuXFWIN

Got back: Here's lookin' at you, kid!

12.3.3. Использование переменной окружения TMPDIR

Многие стандартные утилиты обращают внимание на переменную окружения TMPDIR, используя обозначенный в ней каталог в качестве места для помещения временных файлов. Если TMPDIR не установлена, каталогом по умолчанию для временных файлов обычно является /tmp, хотя на многих современных системах есть также и каталог /var/tmp. /tmp обычно очищается от всех файлов и каталогов административными сценариями оболочки при запуске.

Многие системы GNU/Linux предоставляют каталог /dev/shm, использующий файловую систему типа tmpfs:

$ df

Filesystem 1K-blocks     Used Available Use% Mounted on

/dev/hda2    6198436  5136020    747544  88% /

/dev/hda5   61431520 27720248  30590648  48% /d

none          256616        0    256616   0% /dev/shm

Тип файловой системы tmpfs предоставляет электронный (RAM) диск: часть памяти, которая используется, как если бы она была диском. Более того, файловая система tmpfs использует механизмы виртуальной памяти ядра Linux для его увеличения сверх фиксированного размера. Если на вашей системе уйма оперативной памяти, этот подход может обеспечить заметное ускорение. Чтобы протестировать производительность, мы начали с файла /usr/share/dict/linux.words, который является отсортированным списком правильно написанных слов, по одному в строке. Затем мы перемешали этот файл, так что он больше не был сортированным, и создали больший файл, содержащий 500 копий спутанной версии файла:

$ ls -l /tmp/randwords.big /* Показать размер */

-rw-r--r-- 1 arnold devel 204652500 Sep 18 16:02 /tmp/randwords.big

$ wc -l /tmp/randwords.big /* Сколько слов? */

22713500 /tmp/randwords.big /* Свыше 22 миллионов! */

Затем мы отсортировали файл, используя сначала каталог /tmp, а затем с TMPDIR, установленным в /dev/shm[125]:

$ time sort /tmp/randwords.big > /dev/null

 /* Использование реальных файлов */

real 1m32.566s

user 1m23.137s

sys 0m1.740s

$ time TMPDIR=/dev/shm sort /tmp/randwords.big > /dev/null

 /* Использование электронного диска */

real 1m28.257s

user 1m18.469s

sys 0m1.602s

Интересно, использование электронного диска было лишь незначительно быстрее, чем использование обычных файлов. (В некоторых дальнейших тестах оно было даже в действительности медленнее!) Мы предполагаем, что в игру вступил буферный кэш ядра (см. раздел 4.6.2 «Создание файлов с помощью creat()»), весьма эффективно ускоряя файловый ввод/вывод[126].

У электронного диска есть важный недостаток: он ограничен сконфигурированным для вашей системы размером пространства для подкачки.[127] Когда мы попытались отсортировать файл, содержащий 1000 копий файла с перемешанными словами, место на электронном диске закончилось, тогда как обычный sort завершился благополучно.

Использовать TMPDIR для своих программ просто. Мы предлагаем следующую схему.

const char template[] = "myprog.XXXXXX";

char *tmpdir, *tfile;

size_t count;

int fd;

if ((tmpdir = getenv("TMPDIR")) == NULL)

 /* Использовать значение TMPDIR, если имеется */

 tmpdir = "/tmp"; /* В противном случае, /tmp по умолчанию */

count = strlen(tmpdir) + strlen(template) + 2;

 /* Вычислить размер имени файла */

tfile = (char *)malloc(count); /* Выделить для него память */

if (tfile == NULL) /* Проверка ошибок */

 /* восстановить */

sprintf(tfile, "%s/%s", tmpdir, template);

 /* Создать завершающий шаблон */

fd = mkstemp(tfile); /* Создать и открыть файл */

/* ...использование tempfile через fd... */

close(fd); /* Очистка */

unlink(tfile);

free(tfile);

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

12.4. Совершение самоубийства: abort()

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

#include <stdlib.h> /* ISO С */


void abort(void);

Функция abort() посылает сигнал SIGABRT самому процессу. Это случится, даже если SIGABRT заблокирован или игнорируется. После этого осуществляется обычное для SIGABRT действие, которое заключается в создании дампа ядра.

Примером abort() в действии является макрос assert(), описанный в начале данной главы. Когда assert() обнаруживает, что его выражение ложно, он выводит сообщение об ошибке, а затем вызывает abort() для создания дампа ядра.

В соответствии со стандартом С, осуществляет abort() очистку или нет, зависит от реализации. Под GNU/Linux она выполняет очистку: все потоки <stdio.h> FILE* перед завершением программы закрываются. Обратите, однако, внимание, что для открытых файлов, использующих системные вызовы на основе дескрипторов файлов, ничего не делается. (Если открыты лишь файлы или каналы, ничего не нужно делать. Хотя мы не обсуждали это, дескрипторы файлов используются также для сетевых соединений, и оставление их открытыми является плохой практикой.)

12.5. Нелокальные переходы

«Идите прямо в тюрьму. Не проходите GO. Не забирайте 200$».

- Монополия -
Вы, без сомнения, знаете, чем является goto: передачей потока управления на метку где-то в текущей функции. Операторы goto при скупом употреблении могут послужить удобочитаемости и правильности функции (Например, когда все проверки ошибок используют goto для перехода на метку в конце функции, такую, как clean_up, код с этой меткой проводит очистку [закрывая файлы и т.п.] и возвращается.) При плохом использовании операторы goto могут привести к так называемой «лапше» в коде, логику которого становится невозможно отследить.

Оператор goto в языке С ограничен переходом на метку в текущей функции. Многие языки в семействе Алгола, такие, как Паскаль, допускают использование goto для выхода из вложенной функции в предшествующую вызывающую функцию. Однако в С нет способа, в пределах синтаксиса самого языка, перейти в определенную точку другой функции, пусть даже и вызывающей. Такой переход называется нелокальным переходом.

Почему полезен нелокальный переход? Рассмотрите интерактивную программу, которая считывает и выполняет программы. Предположим, пользователь запускает длительное задание, разочаровывается или меняет мнение о данном задании и нажимает CTRL-С для генерирования сигнала SIGINT. Когда запускается обработчик сигнала, он может перейти обратно в начало главного цикла чтения и обработки команд. Строковый редактор ed представляет простой пример этого:

$ ed -p '> ' sayings /* Запуск ed, '> ' используется как приглашение */

sayings: No such file or directory

> a /* Добавить текст */

Hello, world

Don't panic

^C /* Сгенерировать SIGINT */

? /* Сообщение об ошибке ''один размер подходит всем'' */

> 1,$p /* ed возвращается в командную строку */

Hello, world /* '1,$p' prints all the lines */

Don't panic

> w /* Сохранить файл */

25

> q /* Все сделано */

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

12.5.1. Использование стандартных функций: setjmp() и longjmp()

Нелокальные переходы осуществляются с помощью функций setjmp() и longjmp(). Эти функции используются в двух разновидностях. Традиционные процедуры определены стандартом ISO С:

#include <setjmp.h> /* ISO С */


int setjmp(jmp_buf env);

void longjmp(jmp_buf env, int val);

Тип jmp_buf определен через typedef в <setjmp.h>. setjmp() сохраняет текущее «окружение» в env. env обычно является глобальной или статической на уровне файла переменной, так что она может использоваться из вызванной функции. Это окружение включает любую информацию, необходимую для перехода на местоположение, из которого была вызвана setjmp(). Содержание jmp_buf по своей природе машинно-зависимо; таким образом, jmp_buf является непрозрачным типом: тем, что вы используете, не зная, что находится внутри него.

setjmp() возвращает 0, когда она вызывается для сохранения в jmp_buf текущего окружения. Ненулевое значение возвращается, когда с использованием окружения осуществляется нелокальный переход:

jmp_buf command_loop; /* На глобальном уровне */

/* ... затем в main() ... */

if (setjmp(command_loop) == 0) /* Состояние сохранено, продолжить */

 ;

else /* Мы попадаем сюда через нелокальный переход */

 printf("?\n"); /* ed's famous message */

/* ... теперь начать цикл команд ... */

longjmp() осуществляет переход. Первым параметром является jmp_buf, который должен быть инициализирован с помощью setjmp(). Второй является целым ненулевым значением, которое setjmp() возвращает в первоначальное окружение. Это сделано так, что код, подобный только что показанному, может различить установку окружения и прибытие путем нелокального перехода.

Стандарт С утверждает, что даже если longjmp() вызывается со вторым аргументом, равным 0, setjmp() по-прежнему возвращает ненулевое значение. В таком случае она возвращает 1.

Возможность передать целое значение и вернуться обратно из setjmp() полезна; это позволяет коду уровня пользователя различать причину перехода. Например, gawk использует эту возможность для обработки операторов break и continue внутри циклов. (Язык awk осознанно сделан похожим на С в своем синтаксисе для циклов, с использованием while, do-while, for, break и continue.) Использование setjmp() выглядит следующим образом (из eval.c в дистрибутиве gawk 3.1.3):

507 case Node_K_while:

508  PUSH_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);

509

510  stable_tree = tree;

511  while (eval_condition(stable_tree->lnode)) {

512   INCREMENT(stable_tree->exec_count);

513   switch (setjmp(loop_tag)) {

514   case 0: /* обычный не переход */

515    (void)interpret(stable_tree->rnode);

516    break;

517   case TAG_CONTINUE: /* оператор continue */

518    break;

519   case TAG_BREAK: /* оператор break */

520    RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);

521    return 1;

522   default:

523    cant_happen();

524   }

525  }

526  RESTORE_BINDING(loop_tag_stack, loop_tag, loop_tag_valid);

527  break;

Этот фрагмент кода представляет цикл while. Строка 508 управляет вложенными циклами посредством стека сохраненных переменных jmp_buf. Строки 511–524 выполняют цикл while (используя цикл С while!). Строка 511 проверяет условие цикла. Если оно истинно, строка 513 выполняет switch на возвращаемое значение setjmp(). Если оно равно 0 (строки 514–516), строка 515 выполняет тело оператора. Однако, когда setjmp() возвращает TAG_BREAK или TAG_CONTINUE, оператор switch обрабатывает их соответствующим образом (строки 517–518 и 519–521 соответственно).

Оператор break на уровне awk передает TAG_BREAK функции longjmp(), a continue уровня awk передает TAG_CONTINUE. Снова из eval.c с некоторыми пропущенными не относящимися к делу подробностями:

657 case Node_K_break:

658  INCREMENT(tree->exec_count);

     /* ... */

675  longjmp(loop_tag, TAG_BREAK);

676  break;

677

678 case Node_K_continue:

679  INCREMENT(tree->exec_count);

     /* ... */

696  longjmp(loop_tag, TAG_CONTINUE);

670  break;

Вы можете думать о setjmp() как об установке метки, а о longjmp() как выполнении goto с дополнительным преимуществом возможности сказать, откуда «пришел» код (по возвращаемому значению).

12.5.2. Обработка масок сигналов: sigsetjmp() и siglongjmp()

По историческим причинам, которые, скорее всего, утомили бы вас до слез, стандарт С 1999 г. ничего не говорит о влиянии setjmp() и longjmp() на состояние сигналов процесса, а POSIX явно констатирует, что их влияние на маску сигналов процесса (см. раздел 10.6 «Сигналы POSIX») не определено.

Другими словами, если программа изменяет свою маску сигналов процесса между первым вызовом setjmp() и вызовом longjmp(), каково состояние маски сигналов процесса после longjmp()? Та ли эта маска, когда была впервые вызвана setjmp()? Или это текущая маска? POSIX явно утверждает, что «нет способа это узнать».

Чтобы сделать обработку маски сигналов процесса явной, POSIX ввел две дополнительные функции и один typedef:

#include <setjmp.h> /* POSIX */


int sigsetjmp(sigjmp_buf env, int savesigs); /* Обратите внимание:

                                        sigjmp_buf, не jmp_buf! */

void siglongjmp(sigjmp_buf env, int val);

Главным отличием является аргумент savesigs функции sigsetjmp(). Если он не равен нулю, текущий набор заблокированных сигналов сохраняется в env вместе с остальным окружением, которое сохраняется функцией setjmp(). siglongjmp() с env, в которой savesigs содержала true, восстанавливает сохраненную маску сигналов процесса

ЗАМЕЧАНИЕ. POSIX также ясен в том, что если savesigs равен нулю (false), сохраняется ли маска сигналов процесса или восстанавливается, не определено, как в случае с setjmp()/longjmp(). Это, в свою очередь, предполагает, что если собираетесь использовать 'sigsetjmp(env, 0)', вы также можете не беспокоиться: все дело в том, чтобы иметь контроль над сохранением и восстановлением маски сигналов процесса!

12.5.3. Важные предостережения

Есть несколько технических предостережений, о которых нужно знать.

Во-первых, поскольку сохранение и восстановление среды может быть беспорядочной машинно-зависимой задачей, setjmp() и longjmp() могут быть макросами

Во-вторых, стандарт С ограничивает использование setjmp() следующими ситуациями.

• В качестве единственного контролирующего выражения в операторе цикла или условном операторе (if, switch).

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

• В качестве операнда унарного оператора '!', причем результирующее выражение является единственным контролирующим выражением цикла или условного оператора.

• В качестве всего выражения оператора-выражения, возможно, приведенного к типу void. Например:

(void)setjmp(buf);

В-третьих, если вы хотите изменить локальную переменную в функции, которая вызывает setjmp(), после вызова и хотите, чтобы эта переменная сохранила свое последнее присвоенное после longjmp() значение, нужно объявить эту переменную как volatile. В противном случае все локальные переменные, не являющиеся volatile и изменившиеся после того, как была первоначально вызвана setjmp(), имеют неопределенные значения. (Обратите внимание, что сама переменная jmp_buf не должна объявляться как volatile.) Например:

1  /* ch12-setjmp.с --- демонстрирует setjmp()/longjmp() и volatile. */

2

3  #include <stdio.h>

4  #include <setjmp.h>

5

6  jmp_buf env;

7

8  /* comeback --- выполнение longjmp */

9

10 void comeback(void)

11 {

12  longjmp(env, 1);

13  printf("This line is never printed\n");

14 }

15

16 /* main - вызов setjmp, действия с переменными, вывод значений */

17

18 int main(void)

19 {

20  int i = 5;

21  volatile int j = 6;

22

23  if (setjmp(env) == 0) { /* первый раз */

24   i++;

25   j++;

26   printf("first time: i = %d, j = %d\n", i, j);

27    comeback));

28  } else /* второй раз */

29   printf("second time: i = %d, j = %d\n", i, j);

30

31  return 0;

32 }

В этом примере сохранение своего значения ко второму вызову printf() гарантируется лишь j (строка 21). Значение (строка 20) в соответствии со стандартом С 1999 г. не определено. Это может быть 6, может быть 5, а может даже какое-нибудь другое значение!

В-четвертых, как описано в разделе 12.5.2 «Обработка масок сигналов: sigsetjmp() и siglongjmp()», стандарт С 1999 г. не делает никаких утверждений о влиянии, если оно есть, setjmp() и longjmp() на состояние сигналов программы. Если это важно, вам придется вместо них использовать sigsetjmp() и siglongjmp().

В-пятых, эти процедуры содержат поразительные возможности для утечек памяти! Рассмотрим программу, в которой main() вызывает setjmp(), а затем вызывает несколько вложенных функций, каждая из которых выделяет с помощью malloc() динамическую память. Если наиболее глубоко вложенная функция делает longjmp() обратно в main(), указатели на динамическую память теряются. Взгляните на ch12-memleak.c:

1  /* ch12-memleak.с --- демонстрирует утечки памяти с помощью setjmp()/longjmp(). */

2

3  #include <stdio.h>

4  #include <malloc.h> /* для определения ptrdiff_t в GLIBC */

5  #include <setjmp.h>

6  #include <unistd.h>

7

8  jmp_buf env;

9

10 void f1(void), f2(void);

11

12 /* main --- утечка памяти с помощью setjmp() и longjmp() */

13

14 int main(void)

15 {

16  char *start_break;

17  char *current_break;

18  ptrdiff_t diff;

19

20  start_break = sbrk((ptrdiff_t)0);

21

22  if (setjmp(env) == 0) /* первый раз */

23   printf("setjmp called\n");

24

25  current_break = sbrk((ptrdiff_t) 0);

26

27  diff = current_break - start_break;

28  printf("memsize = %ld\n", (long)diff);

29

30  f1();

31

32  return 0;

33 }

34

35 /* f1 --- выделяет память, осуществляет вложенный вызов */

36

37 void f1(void)

38 {

39  char *p = malloc(1024);

40

41  f2();

42 }

43

44 /* f2 --- выделяет память, выполняет longjmp */

45

46 void f2(void)

47 {

48  char *p = malloc(1024);

49

50  longjmp(env, 1);

51 }

Эта программа устанавливает бесконечный цикл, используя setjmp() и longjmp(). Строка 20 использует для нахождения текущего начала кучи sbrk() (см. раздел 3.2.3 «Системные вызовы: brk() и sbrk()»), а затем строка 22 вызывает setjmp(). Строка 25 получает текущее начало кучи; это место каждый раз изменяется, поскольку longjmp() повторно входит в код. Строки 27–28 вычисляют, сколько было выделено памяти, и выводят это количество. Вот что происходит при запуске:

$ ch12-memleak /* Запуск программы */

setjmp called

memsize = 0

memsize = 6372

memsize = 6372

memsize = 6372

memsize = 10468

memsize = 10468

memsize = 14564

memsize = 14564

memsize = 18660

memsize = 18660

...

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

Каждая из функций f1() и f2() выделяют память, a f2() выполняет longjmp() обратно в main() (строка 51). Когда это происходит, локальные указатели (строки 39 и 48) на выделенную память пропали! Такие утечки памяти может оказаться трудно отследить, поскольку часто выделяются небольшие размеры памяти, и как таковые, они могут оставаться незамеченными в течение ряда лет[128].

Этот код явно патологический, но он предназначен для иллюстрации нашей мысли: setjmp() и longjmp() могут вести к трудно обнаруживаемым утечкам памяти. Предположим, что f1() правильно вызвал free(). Было бы далеко неочевидно, что память никогда не будет освобождена. В более крупной и более реалистичной программе, в которой longjmp() мог быть вызван лишь посредством if, найти такую утечку становится даже еще труднее.

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

В-шестых, longjmp() и siglongjmp() не следует использовать из функций, зарегистрированных посредством atexit() (см. раздел 9.1.5.3 «Функции завершения»).

В-седьмых, setjmp() и longjmp() могут оказаться дорогими операциями на машинах с множеством регистров.

При наличии всех этих проблем вы должны строго рассмотреть дизайн своей программы. Если вам не нужно использовать setjmp() и longjmp(), то, может, стоит обойтись без их использования. Однако, если их использование является лучшим способом структурировать свою программу, продолжайте и используйте их, но делайте это осмотрительно.

12.6. Псевдослучайные числа

Многим приложениям нужны последовательности случайных чисел. Например, игровые программы, имитирующие бросание костей, раздачу карт или вращение барабанов игровой машины, нуждаются в возможности случайного выбора одного из возможных значений. (Подумайте о программе fortune, содержащей большую коллекцию афоризмов; каждый раз при запуске она «случайно» выдает новое высказывание.) Многие криптографические алгоритмы также требуют наличия случайных чисел «высокого качества». В данном разделе описываются различные способы получения последовательностей случайных чисел.

ЗАМЕЧАНИЕ. Природа случайности, генерация случайных чисел и их «качество» являются обширными темами, выходящими за рамки данной книги. Мы предоставляем введение в доступные функции API, но это все, что мы можем сделать Другие источники с более подробной информацией см в разделе 12.9 «Рекомендуемая литература»

Компьютеры по своему строению являются детерминистическими. Одно и то же вычисление с одними и теми же входными данными всегда должно давать одни и те же результаты. Соответственно, они не годятся для генерации истинно случайных чисел, то есть последовательностей чисел, в которых каждое число в последовательности полностью независимо от числа (или чисел), идущих перед ним. Вместо этого разновидности чисел, обычно используемых на программном уровне, называются псевдослучайными числами. То есть в любой данной последовательности номера выглядят независимыми друг от друга, но сама последовательность в целом повторяющаяся. (Эта повторяемость может быть ценным качеством; она обеспечивает детерминизм для программы в целом.)

Многие методы предоставления последовательностей псевдослучайных чисел работают посредством осуществления каждый раз одного и того же вычисления с начальным значением (seed). Сохраненное начальное значение затем обновляется для использования в следующий раз. API предоставляет способ указания нового начального значения. Каждое начальное значение дает одну и ту же последовательность псевдослучайных чисел, хотя различные начальные числа дают (должны давать) различные последовательности.

12.6.1. Стандартный С: rand() и srand()

Стандартный С определяет две связанные функции для псевдослучайных чисел.

#include <stdlib.h> /* ISO С */


int rand(void);

void srand(unsigned int seed);

rand() каждый раз после вызова возвращает псевдослучайное число в диапазоне от 0 до RAND_MAX (включительно, насколько мы можем судить по стандарту C99). Константа RAND_MAX должна быть по крайней мере 32 767; она может быть больше.

srand() дает генератору случайных чисел в качестве начального значения seed. Если srand() никогда не вызывался приложением, rand() ведет себя так, как если бы seed был равен 1.

Следующая программа, ch12-rand.c, использует rand() для вывода граней игральных костей.

1  /* ch12-rand.c --- генерирует игральные кости, используя rand(). */

2

3  #include <stdio.h>

4  #include <stdlib.h>

5

6  char *die_faces[] = { /* Управляет ASCII графика! */

7   "       ",

8   "   *   ", /* 1 */

9   "       ",

10

11  "       ",

12  " *   * ", /* 2 */

13  "       ",

14

15  "       ",

16  " * * * ", /* 3 */

17  "       ",

18

19  " *   * ",

20  "       ", /* 4 */

21  " *   * ",

22

23  " *   * ",

24  "   *   ", /* 5 */

25  " *    * ",

26

27  " * * * ",

28  "       ", /* 6 */

29  " * * * ",

30 };

31

32 /* main --- выводит N различных граней костей */

33

34 int main(int argc, char **argv)

35 {

36  int nfaces;

37  int i, j, k;

38

39  if (argc !=2) {

40   fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);

41   exit(1);

42  }

43

44  nfaces = atoi(argv[1]);

45

46  if (nfaces <= 0) {

47   fprintf(stderr, "usage: %s number-die-faces\n", argv[0]);

48   fprintf(stderr, "\tUse a positive number!\n");

49   exit(1);

50  }

51

52  for (i = 1; i <= nfaces; i++) {

53   j = rand() % 6; /* force to range 0 <= j <= 5 */

54   printf("+-------+\n" );

55   for (k = 0; k < 3; k++)

56    printf("|%s|\n", die_faces[(j * 3) + k]);

57   printf ("+-------+\n\n");

58  }

59

60  return 0;

61 }

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

Ключевой является строка 53, которая преобразует возвращаемое значение rand() в число от нуля до пяти, используя оператор остатка, %. Значение 'j * 3' действует в качестве начального индекса массива die_faces для трех строк, составляющих каждую грань кости. Строки 55 и 56 выводят саму грань. При запуске появляется вывод наподобие этого:

$ ch12-rand 2 /* Вывести две кости */

+-------+

|       |

| *   * |

|       |

+-------+

+-------+

| *   * |

|   *   |

| *   * |

+-------+

Интерфейс rand() восходит еще к V7 и PDP-11. В частности, на многих системах результатом является лишь 16-разрядное число, что значительно ограничивает диапазон чисел, которые могут быть возвращены. Более того, используемый им алгоритм по современным стандартам считается «слабым». (Версия rand() GLIBC не имеет этих проблем, но переносимый код должен быть написан со знанием того, что rand() не является лучшим API для использования.)

ch12-rand.c использует для получения значения в определенном интервале простую методику: оператор %. Эта методика использует младшие биты возвращенного значения (как при десятичном делении, когда остаток отделения на 10 или 100 использует одну или две младшие десятичные цифры). Оказывается, исторический генератор rand() производил лучшие случайные значения в средних и старших битах по сравнению с младшими битами. Поэтому, если вы должны использовать rand(), постарайтесь избежать младших битов. Справочная страница GNU/Linux rand(3) цитирует «Числовые рецепты на С»[129], которая рекомендует эту методику:

j = 1+ (int)(10.0*rand()/(RAND_MAX+1.0)); /* для числа от 1 до 10 */

12.6.2. Функции POSIX: random() и srandom()

BSD 4.3 ввело random() и сопровождающие ее функции. Эти функции используют намного более подходящий генератор случайных чисел, который возвращает 31-разрядное значение. Теперь они входят в расширение XSI, стандартизованное POSIX:

#include <stdlib.h> /* XSI */


long random(void);

void srandom(unsigned int seed);

char *initstate(unsigned int seed, char *state, size_t n);

char *setstate(char *state);

Первые две функции близко соответствуют rand() и srand() и могут использоваться сходным образом. Однако, вместо одного начального значения, которое дает последовательность псевдослучайных чисел, эти функции используют начальное значение вместе с массивом состояния: массивом байтов, который хранит сведения о состоянии для вычисления псевдослучайных чисел. Последние две функции дают возможность управлять массивом состояния.

long random(void);

Возвращает число в диапазоне от 0 до 231-1. (Хотя справочная страница GNU/Linux random(3) говорит между 0 и RAND_MAX, это верно лишь для систем GLIBC, где RAND_MAX равен 231-1. На других системах RAND_MAX может быть меньше. POSIX явно называет диапазон от 0 до 231-1.)

void srandom(unsigned int seed);

Устанавливает начальное число. Если srandom() никогда не вызывается, по умолчанию используется 1.

char *initstate(unsigned int seed, char *state, size_t n);

Инициализирует массив state информацией для использования при генерации случайных чисел, seed является начальным значением, как для srandom(), а n является числом байтов в массиве state.

n должен равняться одному из значений 8, 32, 64, 128 или 256. Большие значения дают лучшие последовательности случайных чисел. Значения меньше 8 заставляют random() использовать простой генератор случайных чисел, сходный с rand(). Значения больше 8, не равные одному из значений в списке, округляются до ближайшего подходящего значения.

char *setstate(char *state);

Устанавливает внутреннее состояние в соответствии с массивом state, который должен быть инициализирован посредством initstate(). Это позволяет переключаться по желанию между различными состояниями, предоставляя множество генераторов случайных чисел.

Если initstate() и setstate() никогда не вызывались, random() использует массив внутреннего состояния размером 128.

Массив state непрозрачен; вы инициализируете его с помощью initstate() и передается функции random() посредством setstate(), но в другом отношении вам не нужно заглядывать в него. Если вы используете initstate() и setstate(). srandom() вызывать не нужно, поскольку начальное значение включено в информацию о состоянии. ch12-random.c использует эти процедуры вместо rand(). Используется также обычная методика, которая заключается в использовании в качестве начального значения генератора случайных чисел времени дня, добавленного к PID.

1  /* ch12-random.c --- генерация вращения костей с использованием random(). */

2

3  #include <stdio.h>

4  #include <stdlib.h>

5  #include <sys/types.h>

6  #include <unistd.h>

7

8  char *die_faces[] = { /* Управляет ASCII графика! */

    /* ... как раньше ... */

32 };

33

34 /* main --- выводит N различных граней кубиков */

35

36 int main(int argc, char **argv)

37 {

38  int nfaces;

39  int i, j, k;

40  char state[256];

41  time_t now;

42

    /* ... проверка args, вычисление nfaces, как раньше ... */

55

56  (void)time(&now); /* В качестве начального значения используются время дня и PID */

57  (void) initstate((unsigned int)(now + getpid()), state, sizeof state);

58  (void)setstate(state);

59

60  for (i = 1; i <= nfaces; i++) {

61   j = random() % 6; /* использовать диапазон 0 <= j <= 5 */

62    printf("+-------+\n");

63    for (k = 0; k < 3; k++)

64     printf("|%s|\n", die_faces[(j * 3) + k]);

65    printf("+-------+\n\n");

66  }

67

68  return 0;

69 }

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

Поскольку она создает последовательности случайных чисел лучшего качества, random() является более предпочтительной по сравнению с rand(), и GNU/Linux и все современные системы Unix ее поддерживают.

12.6.3. Особые файлы /dev/random и /dev/urandom

Как rand(), так и srandom() являются генераторами псевдослучайных чисел. Их вывод для одного и того же начального значения является воспроизводимой последовательностью чисел. Некоторым приложениям, подобным криптографическим, необходимо, чтобы их случайные числа были действительно (более) случайными. С этой целью ядро Linux, также как различные BSD и коммерческие Unix системы предусматривают специальные файлы устройств, которые предоставляют доступ к «энтропийному пулу» случайных битов, которые ядро собирает от физических устройств и других источников. Из справочной страницы random(4):

/dev/random

[Байты, прочитанные из этого файла, находятся] внутри предполагаемого числа шумовых битов в энтропийном пуле, /dev/random должен подходить для использования в случаях, когда необходим высокий уровень случайности, таких, как одноразовая генерация ключа или блока памяти. Когда энтропийный пул пустой, чтение /dev/random будет блокироваться до тех пор, пока не будет собран дополнительный шум окружения.

/dev/urandom

[Это устройство будет] возвращать столько байтов, сколько затребовано. В результате, если нет достаточной энтропии в энтропийном пуле, возвращаемые значения теоретически уязвимы для криптографической атаки алгоритма, использованного драйвером. Знание того, как это сделать, недоступно в современной не секретной литературе, но теоретически возможно существование подобной атаки. Если для вашего приложения это представляет проблему, вместо этого используйте /dev/random.

Для большинства приложений чтения из /dev/urandom должно быть вполне достаточно. Если вы собираетесь написать криптографические алгоритмы высокого качества, следует сначала почитать о криптографии и случайности; не полагайтесь здесь на поверхностное представление! Вот еще одна наша программа для бросания костей, использующая /dev/urandom:

1  /* ch12-devrandom.с --- генерирует бросание костей, используя /dev/urandom. */

2

3  #include <stdio.h>

4  #include <fcntl.h>

5  #include <stdlib.h>

6

7  char *die_faces[] = { /* Управляет ASCII графика! */

    /* ... как ранее ... */

31 };

32

33 /* myrandom --- возвращает данные из /dev/urandom в виде unsigned long */

34

35 unsigned long myrandom(void)

36 {

37  static int fd = -1;

38  unsigned long data;

39

40  if (fd == -1)

41  fd = open("/dev/urandom", O_RDONLY);

42

43  if (fd == -1 || read(fd, &data, sizeof data) <= 0)

44   return random(); /* отступить */

45

46  return data;

47 }

48

49 /* main --- вывести N различных граней кубиков */

50

51 int main(int argc, char **argv)

52 {

53  int nfaces;

54  int i, j, k;

55

    /* ...проверка args, вычисление nfaces, как ранее... */

68

69  for (i = 1; i <= nfaces; i++) {

70   j = myrandom() % 6; /* обеспечить диапазон 0 <= j <= 5 */

71   printf("+-------+\n");

72   for (k = 0; k < 3; k++)

73    printf("|%s|\n", die_faces[(j * 3) + k]);

74   printf("+-------+\n");

75   putchar('\n');

76  }

77

78  return 0;

79 }

Строки 35–47 предоставляют интерфейс вызова функции для /dev/urandom, читая каждый раз данные unsigned long. Издержками является один дескриптор файла, который остается открытым в течение жизни программы.

12.7. Расширения метасимволов

Три набора функции возрастающей сложности предусматривают возможность сопоставления с шаблонами групповых символов оболочки. Многим программам нужны такие библиотечные функции. Одним примером является find: 'find . -name '*.с' -print'. Другим примером является опция --exclude во многих программах, которая принимает шаблон файлов с групповыми символами для исключения из того или иного действия. В данном разделе по очереди рассматривается каждый набор функций.

12.7.1. Простое сопоставление с шаблоном: fnmatch()

Мы начинаем с функции fnmatch() («filename match» сопоставление имени файла»).

#include <fnmatch.h> /* POSIX */


int fnmatch(const char *pattern, const char *string, int flags);

Эта функция сопоставляет string с pattern, который является обычным шаблоном групповых символов оболочки. Значение флагов (которое вскоре будет описано) изменяет поведение функции. Возвращаемое значение равно 0, если string соответствует pattern, FNM_NOMATCH, если не соответствует, и ненулевое значение, если возникла ошибка. К сожалению, POSIX не определяет каких-либо специфических ошибок; соответственно, вы можете лишь сказать, что что-то пошло не так, но не можете сказать, что.

Переменная flags является побитовым ИЛИ одного или более флагов, перечисленных в табл. 12.1.


Таблица 12.1. Значения флагов для fnmatch()

Флаг Только GLIBC Значение
FNM_CASEFOLD Сопоставление с учетом регистра
FNM_FILE_NAME Синоним GNU для FNM_PATHNAME
FNM_LEADING_DIR Флаг для внутреннего использования GLIBC; не используйте его в своих программах. Подробности см. в fnmatch(3)
FNM_NOESCAPE Обратный слеш является обычным символом, а не знаком перехода
FNM_PATHNAME Слеш в string должен соответствовать слешу в pattern, он не может быть подставлен через *, ? или '[...]'
FNM_PERIOD Начальная точка в string подходит, лишь если в pattern также есть начальная точка. Точка должна быть первым символом в string. Однако, если также установленFNM_PATHNAME, точка, которая идет за слешем, также рассматривается как начальная
fnmatch() работает со строками из любого источника; сопоставляемые строки не обязательно должны быть действительными именами файлов. Хотя на практике fnmatch() используется в коде, читающем каталог с помощью readdir() (см раздел 5.3.1 «Базовое чтение каталогов»):

struct dirent dp;

DIR *dir;

char pattern[100];

/* ...заполнить шаблон, открыть каталог, проверить ошибки... */

while ((dp = readdir(dir)) != NULL) {

 if (fnmatch(pattern, dir->d_name, FNM_PERIOD) == 0)

  /* имя файла соответствует шаблону */

 else

  continue; /* не соответствует */

}

GNU ls использует fnmatch() для реализации своей опции --ignore. Вы можете предоставить несколько игнорируемых шаблонов (с помощью нескольких опций). ls сопоставляет каждое имя файла со всеми шаблонами. Она делает это с помощью функции file_interesting() в ls.с:

2269 /* Возвращает не ноль, если файл в 'next' должен быть перечислен. */

2270

2271 static int

2272 file_interesting(const struct dirent *next)

2273 {

2274  register struct ignore_pattern* ignore;

2275

2276  for (ignore = ignore_patterns; ignore; ignore = ignore->next)

2277   if (fnmatch(ignore->pattern, next->d_name, FNM_PERIOD) == 0)

2278    return 0;

2279

2280  if (really_all_files

2281   || next->d_name[0] !=

2282   || (all_files

2283   && next->d_name[1] != '\0 '

2284   && (next->d_name[1] || next->d_name[2] != '\0')))

2285   return 1;

2286

2287  return 0;

2288 }

Цикл в строках 2276–2278 сопоставляет имя файла со списком шаблонов для игнорируемых файлов. Если один из шаблонов подходит, файл не интересен и file_interesting() возвращает false (то есть 0).

Переменная all_files соответствует опции , которая показывает файлы, имена которых начинаются с точки, но не являются '.' и '..'. Переменная really_all_files соответствует опции , которая предполагает , а также показывает '.' и '..'. При наличии таких сведений, условие в строках 228–2284 может быть представлено следующим псевдокодом:

if (/* показать все файлы независимо от их имени (-а) */

 OR /* первый символ имени не точка */

 OR (/* показать файлы с точкой (-А) */

  AND /* в имени файла несколько символов */

  AND (/* второй символ не точка */

   OR /* третий символ не завершает имя */)))

 return TRUE;

ЗАМЕЧАНИЕ. fnmatch() может оказаться дорогостоящей функцией, если она используется в локали с многобайтным набором символов. Обсудим многобайтные наборы символов в разделе 13.4 «Можете произнести это для меня по буквам?»

12.7.2. Раскрытие имени файла: glob() и globfree()

Функции glob() и globfree() более разработанные, чем fnmatch():

#include <glob.h> /* POSIX */


int glob(const char *pattern, int flags,

int (*errfunc)(const char *epath, int eerrno), glob_t *pglob);

void globfree(glob_t *pglob);

Функция glob() осуществляет просмотр каталога и сопоставление с шаблонами, возвращая список всех путей, соответствующих pattern. Символы подстановки могут быть включены в нескольких местах пути, а не только в качестве последнего компонента (например, '/usr/*/*.so'). Аргументы следующие:

const char *pattern

Шаблон для раскрывания.

int flags

Флаги, управляющие поведением glob(), вскоре будут описаны.

int (*errfunc)(const char *epath, int eerrno)

Указатель на функцию для использования при сообщениях об ошибках. Это значение может равняться NULL. Если нет и если (*errfunc)() возвращает ненулевое значение или в flags установлен GLOB_ERR, glob() прекращает обработку. Аргументами (*errfunc)() являются путь, вызвавший проблему, и значение errno, установленное функциями opendir(), readdir() или stat().

glob_t *pglob

Указатель на структуру glob_t, использующуюся для хранения результатов. Структура glob_t содержит список путей, которые выдает glob():

typedef struct {  /* POSIX */

 size_t gl_pathc; /* Число найденных подходящих путей */

 char **gl_pathv; /* Список подходящих путей */

 size_t gl_offs;  /* Слоты для резервирования в gl_pathv */

} glob_t;

size_t gl_pathc

Число путей, которые подошли.

char **gl_pathv

Массив подходящих путей. gl_pathv[gl_pathc] всегда равен NULL.

size_t gl_offs

«Зарезервированные слоты» в gl_pathv. Идея заключается в резервировании слотов спереди от gl_pathv для заполнения их приложением впоследствии, как в случае с именем команды и опциями. Список затем может быть передан непосредственно execv() или execvp() (см. раздел 9.1.4 «Запуск новой программы: семейство exec()»). Зарезервированные слоты устанавливаются в NULL. Чтобы все это работало, в flags должен быть установлен GLOB_DOOFFS.

В табл. 12.2 перечислены стандартные флаги для glob().


Таблица 12.2. Флаги для glob()

Флаг Значение
GLOB_APPEND Добавить результаты текущего вызова к предыдущим
GLOB_DOOFFS Зарезервировать места gl_offs спереди в gl_pathv
GLOB_MARK Добавлять символ / в конец каждого имени, которое обозначает каталог
GLOB_NOCHECK Если шаблон не соответствует имени какого-нибудь файла, вернуть его без изменений
GLOB_NOESCAPE Рассматривать обратный слеш как обычный символ. Это делает невозможным обозначать метасимволы подстановок
GLOB_NOSORT Не сортировать результаты, по умолчанию они сортируются
GLIBC версия структуры glob_t содержит дополнительные члены:

typedef struct { /* GLIBC */

 /* Компоненты POSIX: */

 size_t gl_pathc; /* Число подходящих путей */

 char **gl_pathv; /* Список подходящих путей */

 size_t gl_offs; /* Резервируемые в gl_pathv слоты */

 /* Компоненты GLIBC: */

 int gl_flags; /* Копия флагов, дополнительные флаги GLIBC */

 void (*gl_closedir)(DIR *); /* Частная версия closedir() */

 struct dirent *(*gl_readdir)(DIR *); /* Частная версия readdir)) */

 DIR *(*gl_opendir)(const char *); /* Частная версия opendir)) */

 int (*gl_lstat)(const char *, struct stat *);

  /* Частная версия lstat() */

 int (*gl_stat)(const char *, struct stat *); /* Частная версия stat() */

} glob_t;

Члены структуры следующие:

int gl_flags

Копия флагов. Включает также GLOB_MAGCHAR, если pattern включал какие-либо метасимволы.

void (*gl_closedir)(DIR *)

Указатель на альтернативную версию closedir().

struct dirent *(*gl_readdir)(DIR *)

Указатель на альтернативную версию readdir().

DIR *(*gl_opendir)(const char *)

Указатель на альтернативную версию opendir().

int (*gl_lstat)(const char *, struct stat*)

Указатель на альтернативную версию lstat().

int (*gl_stat)(const char*, struct stat*)

Указатель на альтернативную версию stat().

Указатели на альтернативные версии стандартных функций предназначены главным образом для использования в реализации GLIBC; крайне маловероятно, что вы когда-нибудь их используете. Поскольку GLIBC предусматривает поле gl_flags и дополнительные значения флагов, справочная страница и руководство Info документируют оставшуюся часть структуры GLIBC glob_t. В табл. 12.3 перечислены дополнительные флаги.


Таблица 12.3. Дополнительные флаги GLIBC для glob()

Флаг Значение
GLOB_ALTDIRFUNC Использовать для доступа к каталогам альтернативные функции (см. текст)
GLOB_BRACE Выполнить раскрытие фигурных скобок в стиле csh и Bash.
GLOB_MAGCHAR Вставить gl_flags, если были найдены метасимволы.
GLOB_NOMAGIC Вернуть шаблон, если он не содержит метасимволов
GLOB_ONLYDIR По возможности сопоставлять лишь каталоги. См. текст.
GLOB_PERIOD Разрешить соответствие метасимволов наподобие * и ? начальной точке
GLOB_TILDE Выполнить раскрывание тильды в стиле оболочки.
GLOB_TILDE_CHECK Подобно GLOB_TILDE, но если есть проблемы с указанным домашним каталогом, вернуть GLOB_NOMATCH вместо помещения pattern в список.
Флаг GLOB_ONLYDIR действует в качестве подсказки реализации, потому что вызывающий интересуется лишь каталогами. Главным его предназначением является использование другими функциями в GLIBC, а вызывающий по-прежнему должен быть готов обрабатывать файлы, не являющиеся каталогами. Вам не следует использовать этот флаг в своих программах.

glob() может быть вызвана более одного раза: при первом вызове флаг GLOB_APPEND не должен быть указан, при всех последующих вызовах он должен быть указан. Вы не можете между вызовами изменять gl_offs, а если вы изменили какие-нибудь значения в gl_pathv или gl_pathc, нужно их восстановить перед последующим вызовом glob().

Возможность многократного вызова glob() позволяет накапливать результаты в одном списке. Это довольно практично, приближается к мощным возможностям раскрывания групповых символов оболочки, но на уровне языка программирования С.

glob() возвращает 0, если не было проблем, или одно из значений из табл. 12.4, если были.


Таблица 12.4. Возвращаемые glob() значения

Флаг Значение
GLOB_ABORTED Просмотр остановлен раньше времени, поскольку был установлен GLOB_ERR или функция (*errfunc)() возвратила ненулевой результат
GLOB_NOMATCH Ни одно имя файла не соответствовало pattern, а флаг GLOB_NOCHECK не был установлен
GLOB_NOSPACE Была проблема с выделением динамической памяти
globfree() освобождает всю память, которую динамически выделила glob() Следующая программа, ch12-glob.с, демонстрирует glob():

1  /* ch12-glob.c --- демонстрирует glob(). */

2

3  #include <stdio.h>

4  #include <errno.h>

5  #include <glob.h>

6

7  char *myname;

8

9  /* globerr --- выводит сообщение об ошибке для glob() */

10

11 int globerr(const char *path, int eerrno)

12 {

13  fprintf(stderr, "%s: %s: %s\n", myname, path, strerror(eerrno));

14  return 0; /* let glob() keep going */

15 }

16

17 /* main() --- раскрывает символы подстановки в командной строке и выводит результаты */

18

19 int main(int argc, char **argv)

20 {

21  int i;

22  int flags = 0;

23  glob_t results;

24  int ret;

25

26  if (argc == 1) {

27   fprintf(stderr, "usage: %s wildcard ...\n", argv[0]);

28   exit(1);

29  }

30

31  myname = argv[0]; /* для globerr() */

32

33  for (i = 1; i < argc; i++) {

34   flags |= (i > 1 ? GLOB_APPEND : 0);

35   ret = glob(argv[i], flags, globerr, &results);

36   if (ret != 0) {

37    fprintf(stderr, "%s: problem with %s (%s),

38     stopping early\n", myname, argv[i],

39     /* опасно: */ (ret == GLOB_ABORTED ? "filesystem problem" :

40     ret == GLOB_NOMATCH ? "no match of pattern" :

41     ret == GLOB_NOSPACE ? "no dynamic memory" :

42     "unknown problem"));

43    break;

44   }

45  }

46

47  for (i = 0; i < results.gl_pathc; i++)

48   printf("%s\n", results.gl_pathv[i]);

49

50  globfree(&results);

51  return 0;

52 }

Строка 7 определяет myname, которая указывает на имя программы; эта переменная для сообщений об ошибках от globerr(), определенной в строках 11–15.

Строки 33–45 являются основой программы. Они перебирают в цикле шаблоны, приведенные в командной строке, вызывая для каждого glob() для добавления к списку результатов. Большую часть цикла составляет обработка ошибок (строки 36–44). Строки 47–48 выводят результирующий список, а строки 50–51 проводят завершающую очистку и возвращаются.

Строки 39–41 не являются хорошими; нужно было использовать отдельную функцию, преобразующую целые константы в строки; мы сделали это главным образом ради экономии места. Код наподобие этого может быть сносным для небольших программ, но более крупные должны использовать функцию.

Если вы подумаете о работе, происходящей под капотом (открытие и чтение каталогов, сопоставление шаблонов, динамическое выделение памяти для увеличения списка, сортировка списка), можете качать ценить, как много для вас делает glob()! Вот некоторые результаты:

$ ch12-glob '/usr/lib/x*.so' '../../*.texi'

/usr/lib/xchat-autob5.so

/usr/lib/xchat-autogb.so

../../00-preface.texi

../../01-intro.texi

../../02-cmdline.texi

../../03-memory.texi

...

Обратите внимание, что нам пришлось взять аргументы в кавычки, чтобы предотвратить их разворачивание оболочкой!

Универсализация имен? Что это?
В былые времена, около V6 Unix, для осуществления разворачивания символов подстановки оболочка использовала за кулисами отдельную программу. Эта программа называлась /etc/glob, и согласно исходному коду V6[130], имя «glob» было сокращением от «global».

Таким образом глагол «to glob» проник в лексикон Unix со значением «осуществлять разворачивание символов подстановки». Это, в свою очередь, дает нам имена функций glob() и globfree(). Так что обычно недооцениваемое чувство юмора, время от времени проглядывающее из руководства Unix, все еще живо, официально сохраненное в стандарте POSIX. (Можете ли вы представить кого-нибудь в IBM в 70-х или 80-х годах XX века, называющего системную процедуру glob()?)

12.7.3. Разворачивание слов оболочкой: wordexp() и wordfree()

Многие члены комитета POSIX чувствовали, что glob() делает недостаточно: им нужна была библиотечная процедура, способная делать все, что может делать оболочка разворачивание тильды ('echo ~arnold'), разворачивание переменных оболочки ('echo $HOME') и подстановку команд ('echo $(cd ; pwd)'). Многие другие чувствовали, что glob() не подходила для этой цели. Чтобы «удовлетворить» каждого, POSIX предоставляет две дополнительные функции, которые делают все:

#include <wordexp.h> /* POSIX */


int wordexp(const char *words, wordexp_t *pwordexp, int flags);

void wordfree(wordexp_t *wordexp);

Эти функции работают сходным с glob() и globfree() образом, но со структурой wordexp_t:

typedef struct {

 size_t we_wordc; /* Число подходящих слов */

 char **we_wordv; /* Список развернутых слов */

 size_t we_offs;  /* Резервируемые в we_wordv слоты */

} wordexp_t;

Члены структуры полностью аналогичны описанным ранее для glob_t; мы не будем здесь повторять все описание.

Как и для glob(), поведение wordexp() управляется несколькими флагами. Флаги перечислены в табл. 12.5.


Таблица 12.5. Флаги для wordexp()

Константа Значение
WRDE_APPEND Добавить результаты текущего вызова к предыдущим
WRDE_DOOFFS Зарезервировать we_offs мест в начале we_wordv
WRDE_NOCMD Запретить подстановку команд
WRDE_REUSE Повторно использовать память, на которую указывает we_wordv
WRDE_SHOWERR Не молчать при возникновении во время разворачивания ошибок
WRDE_UNDEF Неопределенные переменные оболочки должны вызывать ошибку
Возвращаемое значение равно 0, если все прошло хорошо, или одно из значений из табл. 12.6, если нет.


Таблица 12.6. Возвращаемые значения ошибок для wordexp()

Константа Значение
WRDE_BADCHAR Метасимвол (конец строки, '|', &, ;, <, >, (, ), {, или }) в недопустимом месте
WRDE_BADVAL Переменная не определена при установленном WRDE_UNDEF
WRDE_CMDSUB Попытка подстановки команды при установленном WRDE_NOCMD
WRDE_NOSPACE Была проблема с выделением динамической памяти
WRDE_SYNTAX Синтаксическая ошибка оболочки.
Мы оставляем вам в качестве упражнения (см. далее) модификацию ch12-glob.c для использования wordexp() и wordfree(). Вот наша версия в действии:

$ ch12-wordexp 'echo $HOME' /* Развертывание переменных оболочки */

echo

/home/arnold

$ ch12-wordexp 'echo $HOME/*.gz' /* Переменные и символы подстановки */

echo

/home/arnold/48000.wav.gz

/home/arnold/ipmasq-HOWTO.tar.gz

/home/arnold/rc.firewall-examples.tar.gz

$ ch12-wordexp 'echo ~arnold' /* Развертывание тильды */

echo

/home/arnold

$ ch12-wordexp 'echo ~arnold/.p*' /* Тильда и символы подстановки */

echo

/home/arnold/.postitnotes

/home/arnold/.procmailrc

/home/arnold/.profile

$ ch12-wordexp "echo '~arnold/.p*'" /* Кавычки работают */

echo

~arnold/.p*

12.8. Регулярные выражения

Регулярные выражения являются способом описания текстовых шаблонов для сопоставления. Если вы вообще сколько-нибудь использовали GNU/Linux или Unix, вы без сомнения знакомы с регулярными выражениями: они являются фундаментальной частью инструментария программиста Unix. Они неотъемлемы от таких повседневных программ, как grep, egrep, sed, awk, Perl, а также редакторы ed, vi, vim и Emacs. Если вы вообще не знакомы с регулярными выражениями, мы рекомендуем ознакомиться с некоторыми из книг или URL, указанных в разделе 12.9 «Рекомендуемая литература».

POSIX определяет два вида регулярных выражений: базовый и расширенный. Программы типа grep, sed и строчный редактор ed используют базовые регулярные выражения. Программы типа egrep и awk используют расширенные регулярные выражения. Следующие функции дают вам возможность использовать в своих программах любой вид.

#include <sys/types.h> /* POSIX */

#include <regex.h>


int regcomp(regex_t *preg, const char *regex, int cflags);

int regexec(const regex_t *preg, const char *string, size_t nmatch,

 regmatch_t pmatch[], int eflags);

size_t regerror(int errcode, const regex_t *preg,

 char *errbuf, size_t errbuf_size);

void regfree(regex_t *preg);

Чтобы сопоставить регулярное выражение, нужно сначала откомпилировать строчную версию регулярного выражения. Компиляция преобразует регулярное выражение во внутренний формат. Затем откомпилированная форма исполняется для строки для проверки, совпадает ли она с первоначальным регулярным выражением. Функции следующие.

int regcomp(regex_t *preg, const char *regex, int cflags)

Компилирует регулярное выражение regex во внутреннее представление, сохраняя его в структуре regex_t, на которую указывает preg. cflags контролирует процесс компиляции; ее значение равно 0 или побитовому ИЛИ одного или более флагов из табл. 12.7

int regexec(const regex_t *preg, const char *string, size_t nmatch,

 regmatch_t pmatch[], int eflags)

Выполняет откомпилированное регулярное выражение в *preg в строке string eflags контролирует способ выполнения; ее значение равно 0 или побитовому ИЛИ одного или более флагов из табл. 12.8. Вскоре мы обсудим другие аргументы.

size_t regerror(int errcode, const regex_t *preg,

 char *errbuf, size_t errbuf_size)

Преобразует ошибку, возвращенную regcomp() или regexec(), в удобочитаемую строку.

void regfree(regex_t *preg)

Освобождает динамическую память, используемую откомпилированным регулярным выражением в *preg.

Заголовочный файл <regex.h> определяет ряд флагов. Некоторые используются с regcomp(); другие используются с regexec(). Однако, все они начинаются с префикса 'REG_'. В табл. 12.7 перечислены флаги для компиляции регулярных выражений с помощью regcomp().


Таблица 12.7. Флаги для regcomp()

Константа Значение
REG_EXTENDED Использовать расширенные регулярные выражения. По умолчанию используются базовые регулярные выражения
REG_ICASE Сопоставление regexec() игнорирует регистр символов
REG_NEWLINE Операторы, заменяющие любой символ, не включают символ конца строки
REG_NOSUB Информация о начале и конце вложенною шаблона не требуется (см текст)
Флаги для сопоставления регулярных выражений с помощью regexec() приведены в табл. 12.8.


Таблица 12.8. Флаги дли regexec()

Константа Значение
REG_NOTBOL Оператор ^ (начало строки) не сопоставляется
REG_NOTEOL Оператор $ (конец строки) не сопоставляется
Флаги REG_NEWLINE, REG_NOTBOL и REG_NOTEOL взаимодействуют друг с другом. Это немного запутано, поэтому мы будем продвигаться небольшими шажками.

• Когда в cflags не включен REG_NEWLINE, символ конца строки действует в качестве обычного символа. С ним может быть сопоставлен метасимвол '.' (любой символ), а также дополненные списки символов ('[^...]'). При этом $ не сопоставляется немедленно с началом вставленного символа новой строки, а ^ не сопоставляется немедленно с его концом.

• Когда в eflags установлен REG_NOTBOL, оператор ^ не соответствует началу строки. Это полезно, когда параметр string является адресом символа в середине сопоставляемого текста.

• Сходным образом, когда в eflags установлен REG_NOTEOL, оператор $ не соответствует концу строки.

• Когда в cflags включен REG_NEWLINE, то:

 • Символ конца строки не соответствует '.' или дополненному списку символов.

 • Оператор ^ всегда соответствует положению непосредственно за вставленным символом конца строки независимо от установки REG_BOL.

 • Оператор $ всегда соответствует положению непосредственно перед вставленным символом конца строки независимо от установки REG_EOL.

Когда вы осуществляете построчный ввод/вывод, как в случае с grep, можно не включать REG_NEWLINE в cflags. Если в буфере несколько строк, и каждую из них нужно рассматривать как отдельную, с сопоставлением ^ и $, тогда следует включить REG_NEWLINE.

Структура regex_t по большей части непрозрачна. Код уровня пользователя может исследовать лишь один член этой структуры; остальное предназначено для внутреннего использования процедурами регулярных выражений:

typedef struct {

 /* ...здесь внутренний материал... */

 size_t re_nsub;

 /* ...здесь внутренний материал... */

} regex_t;

В структуре regmatch_t есть по крайней мере два члена для использования кодом уровня пользователя:

typedef struct {

 /* ...здесь возможный внутренний материал... */

 regoff_t rm_so; /* Смещение начала вложенной строки в байтах */

 regoff_t rm_eo; /* Смещение первого байта после вложенной строки */

 /* ...здесь возможный внутренний материал... */

} regmatch_t;

Как поле re_nsub, так и структура regmatch_t предназначены для сопоставления вложенных выражений. Рассмотрим такое регулярное выражение:

[:пробел:]]+([[:цифра:]]+)[[:пробел:]]+([[:буква:]])+

Каждое из двух вложенных выражений в скобках могут соответствовать одному или более символам. Более того, текст, соответствующий каждому вложенному выражению, может начинаться и заканчиваться в произвольных участках строки.

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

pmatch[0] описывает часть строки, соответствующую всему регулярному выражению. Участок от pmatch[1] до pmatch[preg->re_nsub] описывает ту часть, которая соответствует каждому вложенному выражению в скобках. (Таким образом, вложенные выражения нумеруются начиная с 1.) Элементы rm_so и rm_eo не используемых элементов массива pmatch установлены в -1.

regexec() заполняет не более nmatch-1 элементов pmatch; поэтому следует убедиться, что имеется по крайней мере на 1 элемент больше, чем в preg->re_nsub.

Наконец, флаг REG_NOSUB для regcomp() означает, что начальная и завершающая информация не нужна. Этот флаг следует использовать, когда эти сведения не нужны; это потенциально может довольно значительно повысить производительность regexec().

Другими словами, если все, что вам нужно знать, это «соответствует ли?», включите REG_NOSUB. Однако, если нужно также знать, «где находится соответствующий текст?», этот флаг следует опустить.

В заключение, как regcomp(), так и regexec() возвращают 0, если они успешны, или определенный код ошибки, если нет. Коды ошибок перечислены в табл. 12.9.


Таблица 12.9. Коды ошибок regcomp() и regexec()

Константа Значение
REG_BADBR Содержимое '\{...\}' недействительно.
REG_BADPAT Регулярное выражение недействительно
REG_BADRPT Символу ?, + или * не предшествует действительное регулярное выражение.
REG_EBRACE Фигурные скобки ('\{...\}') не сбалансированы
REG_EBRACK Квадратные скобки ('[...]') не сбалансированы
REG_ECOLLATE В шаблоне использован недействительный элемент сортировки
REG_ECTYPE В шаблоне использован недействительный класс символов
REG_EESCAPE В шаблоне есть завершающий символ \
REG_EPAREN Группирующие скобки ('(...)' или '\(...\)') не сбалансированы
REG_ERANGE Конечная точка в диапазоне не действительна
REG_ESPACE Функции не хватило памяти
REG_ESUBREG Цифра в '\цифра' недействительна
REG_NOMATCH Строка не соответствует шаблону
Для демонстрации регулярных выражений ch12-grep.c предусматривает базовую реализацию стандартной программы grep, которая отыскивает соответствие шаблону. Наша версия использует по умолчанию базовые регулярные выражения. Для использования вместо этого расширенных регулярных выражений она принимает опцию -E, а для игнорирования регистра символов опцию -i. Как и настоящая grep, если в командной строке не указаны файлы, наша grep читает со стандартного ввода, а для обозначения стандартного ввода, как и в настоящей grep, может быть использовано имя файла '-'. (Эта методика полезна для поиска в стандартном вводе наряду с другими файлами.) Вот программа:

1  /* ch12-grep.c - Простая версия grep, использующая функции POSIX */

2

3  #define _GNU_SOURCE 1 /* для getline)) */

4  #include <stdio.h>

5  #include <errno.h>

6  #include <regex.h>

7  #include <unistd.h>

8  #include <sys/types.h>

9

10 char *myname; /* для сообщений об ошибках */

11 int ignore_case = 0; /* опция -i: игнорировать регистр */

12 int extended = 0; /* опция -E: использовать расширенные регулярные выражения */

13 int errors = 0; /* число ошибок */

14

15 regex_t pattern; /* шаблон для поиска */

16

17 void compile_pattern(const char *pat);

18 void process(const char *name, FILE *fp);

19 void usage(void);

Строки 10–15 объявляют глобальные переменные программы. Первый набор (строки 10–13) для опций и сообщений об ошибках. Строка 15 объявляет pattern, в которой хранится откомпилированный шаблон. Строки 17–19 объявляют другие функции программы.

21 /* main --- обработка опций, открывание файлов */

22

23 int main(int argc, char **argv)

24 {

25  int с;

26  int i;

27  FILE *fp;

28

29  myname = argv[0];

30  while ((c = getopt(argc, argv, ":iE")) != -1) {

31   switch (c) {

32   case 'i':

33    ignore_case = 1;

34    break;

35   case 'E':

36    extended = 1;

37    break;

38   case '?':

39    usage();

40    break;

41   }

42  }

43

44  if (optind == argc) /* проверка исправности */

45   usage();

46

47  compile_pattern(argv[optind]); /* компилировать шаблон */

48  if (errors) /* ошибка компиляции */

49   return 1;

50  else

51   optind++;

В строке 29 устанавливается значение myname, а строки 30–45 анализируют опции. Строки 47–51 компилируют регулярное выражение, помещая результаты в pattern, compilе_раttern() увеличивает значение errors, если была проблема. (Соединение функций посредством глобальной переменной, как здесь, обычно считается плохой манерой. Для небольших программ, подобным этой, это сойдет, но для более крупных программ такое сопряжение может стать проблемой.) Если не было ошибок, строка 51 увеличивает значение optind так, что оставшиеся аргументы представляют файлы для обработки.

53  if (optind == argc) /* файлов нет, по умолчанию stdin */

54   process("standard input", stdin);

55  else {

56   /* цикл с файлами */

57   for (i = optind; i < argc; i++) {

58    if (strcmp(argv[i], "-") == 0)

59    process("standard input", stdin);

60    else if ((fp = fopen(argv[i], "r")) != NULL) {

61     process(argv[i], fp);

62     fclose(fp);

63    } else {

64     fprintf(stderr, "%s: %s: could not open: %s\n",

65      argv[0], argv[i], strerror(errno));

66     errors++;

67    }

68   }

69  }

70

71  regfree(&pattern);

72  return errors != 0;

73 }

Строки 53–69 обрабатывают файлы, отыскивая соответствующие шаблону строки. Строки 53–54 обрабатывают случай, когда файлы не указаны: программа читает со стандартного ввода. В противном случае, строки 57–68 обрабатывают в цикле файлы. Строка 58 обрабатывает особый случай '-', обозначающий стандартный ввод, строки 60–62 обрабатывают обычные файлы, а строки 63–67 обрабатывают ошибки.

75 /* compile_pattern --- компиляция шаблона */

76

77 void compile_pattern(const char *pat)

78 {

79  int flags = REG_NOSUB; /* информация о месте совпадения не требуется */

80  int ret;

81 #define MSGBUFSIZE 512 /* произвольно */

82  char error[MSGBUFSIZE];

83

84  if (ignore_case)

85   flags |= REG_ICASE;

86  if (extended)

87   flags |= REG_EXTENDED;

88

89  ret = regcomp(&pattern, pat, flags);

90  if (ret != 0) {

91   (void)regerror(ret, &pattern, error, sizeof error);

92   fprintf(stderr, "%s: pattern '%s': %s\n", myname, pat, error);

93   errors++;

94  }

95 }

Строки 75–95 определяют функцию compile_pattern(). Она сначала устанавливает REG_NOSUB в flags, поскольку нам нужно знать лишь «подходит ли строка?», а не «где в строке располагается подходящий текст?»

Строки 84-85 добавляют дополнительные флаги в соответствии с опциями командной строки. Строка 89 компилирует шаблон, а строки 90–94 сообщают о возникших ошибках

97  /* process --- читает строки текста и сопоставляет их с шаблоном */

98

99  void process(const char *name, FILE *fp)

100 {

101  char *buf = NULL;

102  size_t size = 0;

103  char error[MSGBUFSIZE];

104  int ret;

105

106  while (getline(&buf, &size, fp) != -1) {

107   ret = regexec(&pattern, buf, 0, NULL, 0);

108   if (ret != 0) {

109    if (ret != REG_NOMATCH) {

110     (void)regerror(ret, &pattern, error, sizeof error);

111     fprintf(stderr, "%s: file %s: %s\n", myname, name, error);

112     free(buf);

113     errors++;

114     return;

115    }

116   } else

117   printf("%s: %s", name, buf); /* вывести подходящие строки */

118  }

119  free(buf);

120 }

Строки 97–120 определяют функцию process(), которая читает файл и выполняет сопоставление с регулярным выражением. Внешний цикл (строки 106–119) читает строки ввода. Для избежания проблем с длиной строки мы используем getline() (см. раздел 3.2.1.9 «Только GLIBC: чтение целых строк: getline() и getdelim()»). Строка 107 вызывает regexec(). Ненулевое возвращаемое значение означает либо неудачное сопоставление, либо какую-нибудь другую ошибку. Строки 109–115 соответственно проверяют REG_NOMATCН и выводят ошибку лишь тогда, когда возникла какая-нибудь другая проблема — неудачное сопоставление не является ошибкой

Если возвращаемое значение равно 0, строка совпала с шаблоном и соответственно строка 117 выводит имя файла и совпавшую строку.

122 /* usage --- вывод сообщения об использовании и выход */

123

124 void usage(void)

125 {

126  fprintf(stderr, "usage: %s [-i] [-E] pattern [ files ... ]\n", myname);

127  exit(1);

128 }

Функция usage() выводит сообщение об использовании и завершает программу. Она вызывается, когда предоставлены недействительные аргументы или не предоставлен шаблон (строки 38–40 и 44–45).

Вот и все! Скромная, но тем не менее полезная версия grep в 130 строк кода.

12.9. Рекомендуемая литература

1. Programming Pearls, 2nd edition, by Jon Louis Bentley Addison-Wesley, Reading, Massachusetts, USA, 2000. ISBN- 0-201-65788-0. См. также веб-сайт этой книги.[131]

Проектирование программы с операторами проверки является одной из главных тем в этой книге.

2. Building Secure Software How to Avoid Security Problems the Right Way, by John Viega and Gary McGraw Addison-Wesley, Reading, Massachusetts, USA, 2001. ISBN: 0-201-72152-X.

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

3. The Art of Computer Programming. Volume 2. Seminumerical Algorithms, 3rd edition, by Donald E. Knuth Addison-Wesley, Reading, Massachusetts, USA, 1998. ISBN- 0-201-89684-2.[132] См также веб-сайт этой книги.[133]

Это классическое справочное руководство по генерации случайных чисел.

4. Random Number Generation and Monte Carlo Methods, 2nd edition, by James E. Gentle Springer-Verlag, Berlin, Germany. 2003. ISBN: 0-387-00178-6.

Данная книга широко освещает методы генерации и тестирования псевдослучайных чисел. Хотя для неё также требуется математическая и статистическая подготовка, уровень не такой высокий, как в книге Кнута. (Благодарим Nelson H.F. Beebe за указание этой ссылки.)

5. sed & awk, 2nd edition, by Dale Dougherty and Arnold Robbins. O'Reilly and Associates, Sebastopol, California, USA, 1997. ISBN: 1-56592-225-5.

Эта книга осторожно вводит в регулярные выражения и обработку текста, начиная с grep и продвигаясь к более мощным инструментам sed и awk.

6. Mastering Regular Expressions, 2nd edition, by Jeffrey E.F. Friedl. O'Reilly and Associates, Sebastopol, California, USA, 2002.[134] ISBN: 0-59600-289-0.

Регулярные выражения являются важной частью Unix. Чтобы научиться заменять, вырезать и распределять текст с использованием регулярных выражений, мы рекомендуем эту книгу

7. Руководство для GNU grep также объясняет регулярные выражения. На системе GNU/Linux для просмотра локальной копии вы можете использовать 'info grep'. Или использовать браузер для прочтения онлайн-документации проекта GNU для grep.[135]

12.10. Резюме

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

• Функции memXXX() являются аналогичными более известным функциям strXXX(). Самой большой их ценностью является то. что они могут работать с двоичными данными; нулевые байты не отличаются от других байтов. Больше известна memcpy() против memmove(), обрабатывающей перекрывающиеся копии.

• Временные файлы полезны во многих приложениях. Функции API tmpfile() и mkstemp() являются предпочтительными способами создания временных файлов, в то же время позволяя избежать состояния гонки и связанных с ней проблем безопасности. Многие программы для указания местоположения своих временных файлов используют переменную окружения TMPDIR, а если она не определена, приемлемое значение по умолчанию (обычно /tmp). Это хорошее соглашение, которое следует принять на вооружение в своих программах.

• Функция abort() посылает вызывающему процессу сигнал SIGABRT. Результатом является завершение процесса и создание дампа ядра, предположительно для отладки.

• setjmp() и longjmp() обеспечивают нелокальный переход. Это мощная возможность, которая должна использоваться с осторожностью. sigsetjmp() и siglongjmp() сохраняют и восстанавливают маску сигналов процесса, когда программа осуществляет нелокальный переход. Проблемы с нелокальными переходами иногда перевешивают их преимущества, соответственно используйте эти процедуры лишь когда нет лучшего способа структурировать ваше приложение.

• Случайные числа полезны для множества приложений. Большинство программ используют псевдослучайные числа — последовательности номеров, которые кажутся случайными, но которые могут быть воспроизведены с помощью одного и того же начального значения. rand() и srand() являются первоначальными функциями API, стандартизованными языком С. На многих системах rand() использует низкокачественный алгоритм, random() и srandom() используют лучший алгоритм, включены в стандарт POSIX и являются предпочтительными по сравнению с rand() и srand(). Используйте специальные файлы /dev/random и /dev/urandom, если (а) они доступны и (б) если вам нужны случайные числа высокого качества.

• Три функции API предоставляют все более мощные возможности для развертывания метасимволов (подстановки символов).

  • fnmatch() является простейшей, возвращающей true/false, если данная строка соответствует или не соответствует шаблону символов подстановки оболочки.

  • glob() просматривает файловую систему, возвращая список путей, которые соответствуют данному шаблону. Когда требуются стандартные возможности glob(), следует использовать эту функцию. Хотя GLIBC версия glob() имеет некоторые расширения, переносимые программы, которым нужны дополнительные возможности, должны вместо этого использовать wordexp(). (Программы, которые будут работать лишь на системах GNU/Linux, не должны стесняться использовать полную мощь GLIBC glob().)

  • wordexp() не только делает то, что делает glob(), но также выполняет полное развертывание слов в стиле оболочки, включая развертывание тильды, развертывание переменных оболочки и подстановку команд.

• Функции regcomp() и regexec() обеспечивают доступ к базовым и расширенным регулярным выражениям POSIX. Используя одну из этих функций, можно заставитьсвою программу вести себя идентично со стандартными утилитами, значительно упрощая использование программы пользователями, знакомыми с GNU/Linux и Unix.

Упражнения

1. Используйте read() и memcmp() для написания простой версии программы cmp, которая сравнивает два файла. Вашей версии не нужно поддерживать какие-нибудь опции.

2. Используйте макрос <stdio.h> getc() и прямое сравнение каждого прочитанного символа для написания другой версии cmp, которая сравнивает два файла. Сравните производительность этой версии с производительностью написанной в предыдущем упражнении.

3. (Средней трудности) Рассмотрите функции <stdio.h> fgets() и GLIBC getline(). Полезна ли memcpy() для их реализации? Набросайте с ее использованием возможную реализацию fgets().

4. (Трудное) Найдите исходный код GLIBC версии memcmp(). Он должен быть на одном из CD-ROM с исходным кодом в вашем дистрибутиве GNU/Linux, или же вы можете найти его в сети. Исследуйте код и объясните его.

5. Проверьте свою память. Как tmpfile() организует удаление файла, когда закрыт указатель файла?

6. Используя mkstemp() и fdopen(), а также другие необходимые функции или системные вызовы, напишите свою версию tmpfile(). Протестируйте ее тоже.

7. Опишите преимущества и недостатки использования unlink() для имени файла, созданного mkstemp(), непосредственно после возвращения mkstemp().

8. Напишите свою версию mkstemp(), используя mktemp() и open(). Как вы можете обеспечить те же гарантии уникальности, которые обеспечивает mkstemp()?

9. Программы, использующие mkstemp(), должны обеспечивать удаление файла при завершении. (Предположим, что файл не удаляется сразу же после открытия по тем или иным причинам.) Это включает в себя случай, когда может поступить сигнал завершения. Поэтому удаление файла должно быть частью перехватчика сигнала. Как вы это сделаете?

10. (Трудное) Даже с урезанной очисткой при обработке сигнала все еще имеется состояние гонки. Есть небольшое окно между созданием временного файла функцией mkstemp() и возвращением и записью его имени в переменной (для использования функцией обработки сигнала). Если в это окно попадает не перехваченный сигнал, программа завершается и оставляет временный файл. Как вы закроете это окно? (Спасибо Jim Meyering.)

11. Попробуйте откомпилировать и запустить ch12-setjmp.c на как можно большем количестве различных систем с использованием как можно большего количества различных компиляторов, к каким у вас есть доступ. Попробуйте компилировать с различными уровнями оптимизации. Какие изменения поведения вы видели (если они были)?

12. Посмотрите файл /usr/src/libc/gen/sleep.c в дистрибутиве исходного кода V7 Unix. Он содержит реализацию функции sleep(), описанную в разделе 10.8.1 «Сигнальные часы: sleep(), alarm() и SIGALARM». Распечатайте ее и прокомментируйте в стиле наших примеров, чтобы объяснить ее работу.

13. Посмотрите справочную страницу lrand48(3) на системе GNU/Linux или System V. Выглядит ли этот интерфейс более простым или трудным для использования, чем random()?

14. Возьмите ch08-nftw.c из раздела 8.4.3 «Перемещение по иерархии: nftw()» и добавьте опцию --exclude=pattern. Файлы, соответствующие паттерну, не должны выводиться.

15. (Трудное) Почему GLIBC нужны указатели на альтернативные версии функций стандартных каталогов и stat()? Не может ли она вызывать их непосредственно?

16. Измените ch12-glob.c для использования функции wordexp(). Поэкспериментируйте с ней, проделав несколько дополнительных вещей, которые она предоставляет. Не забудьте взять аргументы командной строки в кавычки, чтобы wordexp() на самом деле выполнила свою работу!

17. Стандартная grep выводит имя файла, лишь когда в командной строке указано больше одного файла. Сделайте так, чтобы ch12-grep.c действовала таким же образом.

18. Посмотрите справочную страницу grep(1). Добавьте к ch12-grep.c стандартные опции -e, -s и -v.

19. Напишите простую замещающую программу:

subst [-g] шаблон подстановка [файлы ...]

Она должна читать текстовые строки из указанных файлов или из стандартного ввода, если они не указаны. Каждая строка должна сравниваться на соответствие шаблону. Если обнаружено соответствие, оно должно замещаться подстановкой.

Если указана опция -g, замещаться должно не только первое совпадение, но и все остальные совпадения в строке.

Глава 13 Интернационализация и локализация

Ранние вычислительные системы обычно для своего вывода (приглашений, сообщений об ошибках) и ввода (ответы на запросы, такие, как «да» и «нет») использовали английский язык. Это было верно для систем Unix вплоть до середины 1980-х. В конце 80-х, начиная с первого стандарта ISO для С и продолжая стандартами POSIX 1990-х и современным стандартом POSIX, были разработаны возможности для работы программ на нескольких языках без необходимости поддержки нескольких версий одной и той же программы. Данная глава описывает, как современные программы должны справляться с многоязычными проблемами.

13.1. Введение

Центральной концепцией является окружение, место, в котором работает программа. Локали содержат в себе следующие сведения: локальный набор символов; сведения о формате отображения даты и времени; форматирование и отображение денежных сумм; форматирование и отображение числовых значений (с или без разделителей тысяч, какой символ используется в качестве разделителя дробной части числа и т.д.).

Интернационализация является процессом написания (или изменения) программы таким образом, что она может работать с различными локалями. Локализация является процессом приспособления интернационализированной программы для определенной локали. Часто вместо этих терминов используют сокращения i18n и l10n соответственно. (Числовое значение указывает, сколько букв в середине слова, а эти сокращения имеют небольшое сходство с полными терминами.[136] Их также гораздо легче набирать.) Другим часто встречающимся термином является поддержка родного языка, обозначаемая как NLS[137]; NLS обозначает программную поддержку для i18n и l10n.

Кроме того, некоторые люди используют термин глобализация (сокращенно g10n) для обозначения процесса подготовки всех возможных локализаций для интернационализированной программы. Другими словами, подготовки программы для глобального использования.

Возможности NLS существуют на двух уровнях. Первым уровнем является библиотека С. Она предоставляет сведения о локали; процедуры для обработки большей части низкоуровневых подробностей работы по форматированию даты/времени, числовых и денежных значений; и процедуры для корректного для данной локали сопоставления регулярных выражений и классификации символов и сравнений. Именно возможности библиотеки появляются в стандартах С и POSIX.

На уровне приложения GNU gettext предоставляет команды и библиотеку для локализации программы: т.е. для возможности вывода сообщений на одном или более естественных языках. GNU gettext основана на плане, первоначально разработанном Sun Microsystems для Solaris[138]; однако, она была реализована с нуля и теперь предоставляет расширения к первоначальному gettext Solaris. GNU gettext является стандартом де-факто для локализации программ, особенно в мире GNU.

В дополнение к локалям и gettext стандарт С предоставляет возможности для работы с несколькими наборами символов и с их кодировками — способом представления больших наборов символов с помощью меньшего числа байтов. Мы кратко затронем эти проблемы в конце главы.

13.2. Локали и библиотека С

Специфичное для локали поведение управляется посредством установки переменных окружения, описывающих, какую локаль (локали) использовать для той или иной информации. Число доступных локалей, предлагаемых каждой конкретной операционной системой, колеблется от менее чем десяти на некоторых коммерческих системах Unix до сотен локалей на системах GNU/Linux. ('locale -a' выводит полный список доступных локалей.)

Гарантируется существование двух локалей, «С» и «POSIX». Они действуют в качестве локали по умолчанию, предоставляя окружение 7-разрядного ASCII, поведение которого такое же, как на традиционных системах Unix без поддержки локалей. В противном случае, локали обозначают язык, страну, а также могут включать сведения о наборе символов. Например, 'it_IT' используется для итальянского языка в Италии с использованием системного набора символов по умолчанию, a 'it_IT.UTF-8' использует кодировку UTF-8 для набора символов Unicode.

Дополнительные подробности об именах локалей можно найти в справочной странице GNU/Linux setlocale(3). Обычно дистрибутивы GNU/Linux устанавливают для системы локаль по умолчанию при ее установке, основываясь на языке, выбранном тем кто устанавливал ее, и пользователям больше не приходится об этом беспокоиться.

13.2.1. Категории локалей и переменные окружения

Заголовочный файл <locale.h> определяет функции и структуры локали. Категории локали определяют разновидности информации, которые будут для программы зависимы от локали. Категории доступны в виде набора именованных констант. Они перечислены в табл. 13.1.


Таблица 13.1. Константы категорий локалей ISO С, определенные в <locale.h>

Категория Значение
LC_ALL Эта категория включает всю возможную информацию локали. Она состоит из оставшейся части элементов этой таблицы
LC_COLLATE Категория для сравнения строк (обсуждаемого ниже) и областей регулярных выражений
LC_CTYPE Категория для классификации символов (заглавные, строчные и т.д.) Это влияет на сопоставление регулярных выражений и функции isXXX() в <ctype.h>
LC_MESSAGES Категория для специфичных для локали сообщений. Эта категория вступает в игру с GNU gettext, которая обсуждает далее в главе
LC_MONETARY Категория для форматирования денежной информации, такой, как локальные и международные символы для местной валюты (например, $ против USD для доллара США), форматирования отрицательных величин и т.д.
LC_NUMERIC Категория для форматирования числовых значений
LC_TIME Категория для форматирования дат и времени
Эти категории определены различными стандартами. Некоторые системы могут поддерживать дополнительные категории, такие, как LC_TELEPHONE или LC_ADDRESS. Однако, они не стандартизованы; любой программе, которой нужно их использовать, но которая все равно должна быть переносимой, следует использовать #ifdef для окружения соответствующих разделов.

По умолчанию, программы С и библиотека С ведут себя так, как если бы они находились в локали «С» или «POSIX» для обеспечения обратной совместимости со старыми системами. Однако, вызвав setlocale() (как описано ниже), программа может включить действие локали. После того, как программа это сделала, пользователь может, установив переменные окружения, включать и выключать возможности локали, которые будет иметь программа.

Переменные окружения имеют те же самые имена, что и перечисленные в табл. 13.1 категории локалей. Таким образом, команда —

export LC_NUMERIС=en_DK LC_TIME=C

— определяет, что числа должны выводиться в соответствии с локалью 'en_DK' (английский язык в Дании), но что значения даты и времени должны выводиться в соответствии с обычной локалью 'С'. (Этот пример просто иллюстрирует, что вы можете указывать для различных категорий различные локали; это не является чем-то обязательным, что вы должны делать.)

Переменная окружения LC_ALL перекрывает все другие переменные LC_xxx. Если LC_ALL не установлена, библиотека ищет определенные переменные (LC_CTYPE, LC_MONETARY и т.д.). Наконец, если ни одна из них не установлена, библиотека ищет переменную LANG. Вот небольшая демонстрация с использованием gawk:

$ unset LC_ALL LANG /* Удалить переменные по умолчанию */

$ export LС_NUMERIC=en_DK LC_TIME=C

 /* Европейские числа, дата и время по умолчанию */

$ gawk 'BEGIN { print 1.234 ; print strftime() }'

 /* Вывести число, текущие дату и время */

1,234

Wed Jul 09 09:32:18 PDT 2003

$ export LC_NUMERIC=it_IT LC_TIME=it_IT

 /* Итальянские числа, дата и время */

$ gawk 'BEGIN { print 1.234 ; print strftime() }'

 /* Вывести число, текущие дату и время */

1,234

mer lug 09 09:32:40 PDT 2003

$ export LC_ALL=C /* Установить перекрывающую переменную */

$ gawk 'BEGIN { print 1.234 ; print strftime() }'

 /* Вывести число, текущие дату и время */

1.234

Wed Jul 09 09:33:00 PDT 2003

Для awk стандарт POSIX констатирует, что числовые константы в исходном коде всегда используют в качестве десятичного разделителя '.' тогда как числовой вывод следует правилам локали).

Почти все GNU версии стандартных утилит Unix могут использовать локали. Таким образом, особенно на системах GNU/Linux, установка этих переменных позволяет вам контролировать поведение системы[139].

13.2.2. Установка локали: setlocale()

Как уже упоминалось, если вы ничего не делаете, программы на С и библиотека С ведет себя так, как если бы использовалась локаль «С». Функция setlocale() устанавливает соответствующую локаль:

#include <locale.h> /* ISO С */


char *setlocale(int category, const char *locale);

Аргумент category является одной из категорий, описанных в разделе 13.2.1 «Категории локалей и переменные окружения». Аргумент locale является строкой, именующей используемую для этой категории локаль. Когда locale является пустой строкой (""), setlocale() проверяет соответствующие переменные окружения.

Если locale равно NULL, сведения о локали не изменяются. Вместо этого функция возвращает строку, представляющую текущую локаль для данной категории.

Поскольку каждая категория может быть установлена индивидуально, автор приложения решает, насколько будет программа использовать локаль. Например, если main() делает лишь это —

setlocale(LC_TIME, "");

 /* Использование локали только для времени и все */

— тогда, независимо от установленных в окружении других переменных LC_xxx, локали подчиняются лишь функции времени и даты. Все остальные действуют так, как если бы программа по-прежнему работала в локали «С». Сходным образом вызов:

setlocale(LC_TIME, "it_IT"); /* Время всегда итальянское */

заменяет переменную окружения LC_TIME (также, как LC_ALL), заставляя программу использовать для вычислений времени/даты данные для Италии. (Хотя Италия может быть прекрасным местом, программам лучше использовать "", чтобы они могли корректно работать везде; этот пример предназначен лишь для объяснения того, как работает setlocale().)

Можно индивидуально вызывать setlocale() для каждой категории, но простейшим способом является установка всего одним махом:

/* Находясь в Риме, вместо «всего» делайте все как римляне. :-) */

setlocale(LC_ALL, "");

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

char *initial_locale;

initial_locale = strdup(setlocale(LC_ALL, "")); /* сохранить копию */

...

(void)setlocale(LC_ALL, initial_locale); /* восстановить ее */

Здесь мы сохранили копию, использовав функцию POSIX strdup() (см. раздел 3.2.2 «Копирование строк: strdup()»).

13.2.3. Сравнение строк: strcoll() и strxfrm()

Знакомая функция strcmp() сравнивает две строки, возвращая отрицательное, нулевое или положительное значения, если первая строка меньше, равна или больше второй. Это сравнение основано на числовых значениях символов в машинном наборе символов. Из-за этого результаты strcmp() никогда не изменяются.

Однако, при наличии локалей простого числового сравнения недостаточно. Каждая локаль определяет для содержащихся в ней символов последовательность сортировки, другими словами, относительный порядок символов внутри локали. Например, в простом 7-битном ASCII у двух символов 'А' и 'а' десятичные значения равны 65 и 97 соответственно. Соответственно, во фрагменте

int i = strcmp("А", "a");

i имеет отрицательное значение. Однако, в локали "en_US.UTF-8" 'A' идет после 'a', а не перед ним. Таким образом, использование strcmp() для приложений, использующих локаль, является плохой мыслью, мы могли бы сказать, что она возвращает игнорирующий локаль ответ.

Функция strcoll() (string collate — сортировка строк) существует для сравнения строк с использованием локали:

#include <string.h> /* ISO С */


int strcoll(const char *s1, const char *s2);

Она возвращает такие же отрицательные/нулевые/положительные значения, что и strcmp(). Следующая программа, ch13-compare.c, интерактивно демонстрирует разницу:

1  /* ch13-compare.с --- демонстрация strcmp() против strcoll() */

2

3  #include <stdio.h>

4  #include <locale.h>

5  #include <string.h>

6

7  int main(void)

8  {

9  #define STRBUFSIZE 1024

10  char locale[STRBUFSIZE], curloc[STRBUFSIZE];

11  char left[STRBUFSIZE], right[STRBUFSIZE];

12  char buf[BUFSIZ];

13  int count;

14

15  setlocale(LC_ALL, ""); /* установить локаль */

16  strcpy(curloc, setlocale(LC_ALL, NULL)); /* сохранить ее */

17

18  printf("--> "); fflush(stdout);

19  while (fgets(buf, sizeof buf, stdin) != NULL) {

20   locale[0] = '\0';

21   count = sscanf(buf, "%s %s %s", left, right, locale);

22   if (count < 2)

23    break;

24

25   if (*locale) {

26    setlocale(LC_ALL, locale);

27    strcpy(curloc, locale);

28   }

29

30   printf("%s: strcmp(\"%s\", \"%s\") is %d\n", curloc, left,

31    right, strcmp(left, right));

32   printf("%s: strcoll(\"%s\", \"%s\") is %d\n", curloc, left,

33    right, strcoll(left, right));

34

35   printf("\n--> "); fflush(stdout);

36  }

37

38  exit(0);

39 }

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

Массив curloc сохраняет текущую локаль для вывода результатов; left и right являются левым и правым сравниваемыми словами (строки 10–11). Основную часть программы составляет цикл (строки 19–36), который читает строки и выполняет работу. Строки 20–23 разделяют входную строку, locale инициализируется пустой строкой, если третья строка не предусмотрена.

Строки 25–28 устанавливают новую локаль, если она приведена. Строки 30–33 выводят результаты сравнения, а строка 35 приглашает для дальнейшего ввода. Вот демонстрация:

$ ch13-compare /* Запуск программы */

--> ABC abc /* Ввести два слова */

С: strcmp("ABC", "abc") is -1 /* Программа началась в локали "С" */

С: strcoll("ABC", "abc") is -1 /* В локали "С" идентичные рез-ты */


--> ABC abc en_US /* Слова те же, локаль "en_US" */

en_US: strcmp("ABC", "abc") is -1 /* strcmp() без изменений */

en_US: strcoll("ABC", "abc") is 2 /* рез-ты strcoll() изменились' */


--> ABC abc en_US.UTF-8 /* Слова те же, локаль "en_US.UTF-8" */

en_US.UTF-8: strcmp("ABC", "abc") is -1

en_US. UTF-8: strcoll("ABC", "abc") is 6

 /* Другое значение, все еще положительное */


--> junk JUNK /* Новые слова */

en_US.UTF-8: strcmp("junk", "JUNK") is 1 /* предыдущая локаль */

en_US.UTF-8: strcoll("junk", "JUNK") is -6

Эта программа ясно показывает различие между strcmp() и strcoll(). Поскольку strcmp() работает в соответствии с числовыми значениями символов, она всегда возвращает тот же самый результат, strcoll() понимает проблемы сортировки, и ее результат меняется в соответствии с локалью. Мы видим, что в обеих локалях en_US заглавные буквы идут после строчных.

ЗАМЕЧАНИЕ. Специфическая для локали сортировка строк является проблемой также и для сопоставления регулярных выражений. Регулярные выражения допускают диапазоны символов внутри выражений со скобками, такие, как '[a-z]' или '["-/]'. Точное значение такой конструкции (символы, численно располагающиеся между начальной и конечной точками включительно) определено лишь для локалей «С» и «POSIX»

Для локалей, не являющихся ASCII, такие диапазоны как '[a-z]' могут соответствовать также и заглавным буквам, а не только строчным! Диапазон '["-/]' действителен в ASCII, но не в "en_US.UTF-8".

Долговременным наиболее переносимым решением является использование классов символов POSIX, таких, как '[[:lower:]]' и '[[:punct:]]'. Если вам кажется, что нужно использовать выражения с диапазонами на системах, использующих локали, и на более старых системах, не использующих их, без изменения своей программы, решение заключается в применении грубой силы и индивидуальном перечислении каждого символа внутри скобок. Это неприятно, но это работает.

Основанная на локалях сортировка потенциально дорогостоящая. Если вы ожидаете большого числа сравнений, где по крайней мере одна из строк не будет изменяться или где значения строк будут сравниваться друг с другом по несколько раз (как при сортировке списка), следует рассмотреть использование функции strxfrm() для преобразования своих строк для использования с strcmp(). Функция strxfrm() объявлена следующим образом:

#include <string.h> /* ISO С */


size_t strxfrm(char *dest, const char *src, size_t n);

Идея в том, что strxfrm() преобразует первые n символов src, помещая их в dest. Возвращаемое значение является числом символов, необходимых для сохранения преобразованных символов. Если она превышает n, содержимое dest «неопределенно».

Стандарт POSIX явным образом разрешает устанавливать в n ноль, а в dest NULL. В этом случае strxfrm() возвращает размер массива, необходимого для сохранения преобразованной версии src (не включая завершающий символ '\0'). Предполагается, что это значение впоследствии будет использовано с malloc() для создания массива dest или для проверки размера предопределенных границ массива (При этом, очевидно, src должен иметь завершающий нулевой байт.) Этот фрагмент иллюстрирует использование strxfrm():

#define STRBUFSIZE ...

char s1[STRBUFSIZE], s2[STRBUFSIZE]; /* Оригинальные строки */

char s1x[STRBUFSIZE], s2x[STRBUFSIZE]; /* Преобразованные копии */

size_t len1, len2;

int cmp;


/* ... заполнить s1 и s2 ... */

len1 = strlen(s1);

len2 = strlen(s2);


if (strxfrm(s1x, s1, len1) >= STRBUFSIZE ||

 strxfrm(s2x, s2, len2) >= STRBUFSIZE)

 /* слишком большой, восстановить */


cmp = strcmp(s1x, s2x);

if (cmp == 0)

 /* равны */

else if (cmp < 0)

 /* s1 < s2 */

else

 /* s1 > s2 */

Для одноразовых сравнений, возможно, быстрее непосредственно использовать strcoll(). Но если строки будут сравниваться несколько раз, более быстрым будет использование сначала strxfrm(), а затем strcmp() с преобразованными значениями. Функций для локали, соответствующих strncmp() или strcasecmp(), нет.

13.2.4. Числовое и денежное низкоуровневое форматирование: localeconv()

Корректное форматирование числовых и денежных значений требует значительной низкоуровневой информации. Указанная информация доступна в struct lconv, которую получают с помощью функции localeconv():

#include <locale.h> /* ISO С */


struct lconv *localeconv(void);

Подобно функции ctime(), эта функция возвращает указатель на внутренние статические данные. Следует сделать копию возвращенных данных, поскольку последующие вызовы могут возвратить другие значения, если локаль изменилась. Вот struct lconv (слегка сжатая), непосредственно из GLIBC <locale.h>:

struct lconv {

 /* Числовая (не денежная) информация. */

 char *decimal_point; /* Разделитель десятичной дроби. */

 char *thousands_sep; /* Разделитель тысяч. */

 /* Каждый элемент является числом цифр в каждой группе;

    элементы с большими индексами оставлены дальше. Элемент со

    значением CHAR_MAX означает, что дальнейшая группировка не

    производится. Элемент со значением 0 означает, что предыдущий

    элемент используется для всех оставшихся групп. */

 char *grouping;

 /* Денежная информация. */

 /* Первые три символа являются символами валют из ISO 4217.

    Четвертый символ является разделителем. Пятый символ '\0'. */

 char *int_curr_symbol;

 char *currency_symbol; /* Символ местной валюты. */

 char *mon_decimal_point; /* Символ десятичной точки. */

 char *mon_thousands_sep; /* Разделитель тысяч. */

 char *mon_grouping; /* Аналогично элементу 'группировки' (выше). */

 char *positive_sign; /* Знак для положительных значений. */

 char *negative_sign; /* Знак для отрицательных значений. */

 char int_frac_digits; /* Международные цифры дробей. */

 char frac_digits; /* Местные цифры дробей. */

 /* 1, если символ валюты перед положит, значением, 0, если после. */

 char p_cs_precedes;

 /* 1, если символ валюты отделяется от положит, значения пробелом. */

 char p_sep_by_space;

 /* 1, если символ валюты перед отриц. значением, 0, если после. */

 char n_cs_precedes;

 /* 1, если символ валюты отделяется от отриц. значения пробелом. */

 char n_sep_by_space;

 /* Размещение положительного и отрицательного знака:

    0 Количество и символ валюты окружены скобками.

    1 Строка знака перед количеством и символом валюты.

    2 Строка знака за количеством и символом валюты.

    3 Строка знака непосредственно перед символом валюты.

    4 Строка знака непосредственно после символа валюты. */

 char p_sign_posn;

 char n_sign_posn;

 /* 1, если int_curr_symbol до положит. значения, 0, если после. */

 char int_p_cs_precedes;

 /* 1, если int_curr_symbol отделен от положит, знач. пробелом. */

 char int_p_sep_by_space;

 /* 1, если int_curr_symbol перед отриц. значением, 0, если после. */

 char int_n_cs_precedes;

 /* 1, если int_curr_symbol отделен от отриц. знач. пробелом. */

 char int_n_sep_by_space;

 /* Размещение положительного и отрицательного знака:

    0 Количество и int_curr_symbol окружены скобками.

    1 Строка знака до количества и int_curr_symbol.

    2 Строка знака после количества и int_curr_symbol.

    3 Строка знака непосредственно до int_curr_symbol.

    4 Строка знака непосредственно после int_curr_symbol. */

 char int_p_sign_posn;

 char int_n_sign_posn;

};

Комментарии показывают довольно ясно, что происходит. Давайте посмотрим на несколько первых полей struct lconv:

decimal_point

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

thousands_sep

Символ, используемый для разделения каждых 3 цифр значения.

grouping

Массив однобайтных целых значений. Каждый элемент указывает, сколько цифр в группе. Как сказано в комментарии, CHAR_MAX означает, что дальше группировка не используется, а 0 означает повторное использование последнего элемента (Далее в главе мы покажем пример кода.)

int_curr_symbol

Это международный символ для местной валюты. Например, 'USD' для доллара США.

currency_symbol

Локальный символ для местной валюты. Например, $ для доллара США.

mon_decimal_point, mon_thousands_sep, mon_grouping

Соответствуют предыдущим полям, предоставляя те же сведения, но для денежных сумм.

Большая часть оставшихся значений не имеет значения для повседневного программирования. Следующая программа, ch13-lconv.c, выводит некоторые из этих значений, чтобы дать вам представление, для какого рода сведений они используются:

/* ch13-lconv.c --- показывает некоторые компоненты struct lconv */

#include <stdio.h>

#include <limits.h>

#include <locale.h>


int main(void) {

 struct lconv l;

 int i;


 setlocale(LC_ALL, "");

 l = *localeconv();


 printf("decimal_point = [%s]\n", l.decimal_point);

 printf("thousands_sep = [%s]\n", l.thousands_sep);


 for (i = 0; l.grouping[i] != 0 && l.grouping[i] != CHAR_MAX; i++)

  printf("grouping[%d] = [%dj\n", i, l.grouping[i]);


 printf("int_curr_symbol = [%s]\n", l.int_curr_symbol);

 printf("currency_symbol = f%s]\n", l.currency_symbol);

 printf("mon_decimal_point = f%s]\n", l.mon_decimal_point);

 printf("mon_thousands_sep = [%s]\n", l.mon_thousands_sep);

 printf("positive_sign = [%s]\n", l.positive_sign);

 printf("negative_sign = [%s]\n", l.negative_sign);

}

Неудивительно, при запуске в различных локалях мы получаем различные результаты.

$ LC_ALL=en_US ch13-lconv /* Результаты для Соединенных Штатов */

decimal_point = [.]

thousands_sep = [,]

grouping[0] = [3]

grouping[1] = [3]

int_curr_symbol = [USD ]

currency_symbol = [$]

mon_decimal_point = [.]

mon_thousands_sep = [,]

positive_sign = []

negative_sign = [-]

$ LC_ALL=it_IT ch13-lconv /* Результаты для Италии */

decimal_point = [.]

thousands_sep = []

int_curr_symbol = []

currency_symbol = []

mon_decimal_point = []

mon_thousands_sep = []

positive_sign = []

negative_sign = []

Обратите внимание, что значение int_curr_symbol в локали "en_US" включает завершающий символ пробела, который служит для отделения символа от последующего денежного значения.

13.2.5. Высокоуровневое числовое и денежное форматирование: strfmon() и printf()

После рассмотрения всех полей struct lconv вы можете поинтересоваться: «Нужно ли мне на самом деле выяснять, как использовать все эти сведения, просто для форматирования денежного значения?» К счастью, ответом является «нет».[140] Функция strfmon() делает за вас всю работу:

#include <monetary.h> /* POSIX */


ssize_t strfmon(char *s, size_t max, const char *format, ...);

Эта функция во многом подобна strftime() (см. раздел 6.1.3.2 «Сложное форматирование времени: strftime()»), используя format для копирования символов букв и форматированных числовых значений в s, помещая в нее не более max символов. Следующая простая программа, ch13-strfmon.c, демонстрирует работу strfmon():

/* ch13-strfmon.c --- демонстрация strfmon() */

#include <stdio.h>

#include <locale.h>

#include <monetary.h>


int main(void) {

 char buf[BUFSIZ];

 double val = 1234.567;


 setlocale(LC_ALL, "");

 strfmon(buf, sizeof buf, "You owe me %n (%i)\n", val, val);

 fputs(buf, stdout);

 return 0;

}

При запуске в двух различных локалях она выдает такой результат:

$ LC_ALL=en_US ch13-strfmon /* В Соединенных Штатах */

You owe me $1,234.57 (USD 1,234.57)

$ LC_ALL=it_IT ch13-strfmon /* В Италии */

You owe me EUR 1.235 (EUR 1.235)

Как вы можете видеть, strfmon() подобна strftime(), копируя обычные символы в буфер назначения без изменений и форматируя аргументы в соответствии со своими собственными спецификациями форматирования. Их всего три.

%n  Вывести национальное (т.е. местное) представление значения валюты.

%i  Вывести международное представление значения валюты.

%%  Вывести символ '%'.

Форматируемые значения должны иметь тип double. Разницу между %n и %i мы видим в локали "en_US": %n использует символ $, тогда как %i использует USD, которая означает «доллары США».

Гибкость — и соответственно определенная сложность — сопровождают многие функции API, разработанные для POSIX, и strfmon() не является исключением. Как и с printf(), несколько необязательных элементов, которые могут быть между % и i или n, обеспечивают повышенный контроль. Полные формы следующие:

%[флаги][ширина поля][#точность_слева][.точность_справа]i

%[флаги][ширина поля][#точность_слева][.точность_справа]n

%% /* Не допускаются поля флагов, ширины и т.д. */

Флаги перечислены в табл. 13.2.


Таблица 13.2. Флаги для strfmon()

Флаг Значение
Использовать символ с в качестве символа числового заполнения слева. Символом по умолчанию является пробел. Обычной альтернативой является 0
^ Запретить использование символа группировки (например, запятой в Соединенных Штатах)
( Отрицательные значения заключать в скобки. Несовместим с флагом +
+ Обрабатывать положительные/отрицательные значения обычным образом. Использовать положительные и отрицательные знаки локали. Несовместим с флагом (
! Не включать символ валюты. Этот флаг полезен, если вы хотите использовать strfmon() для более гибкого форматирования обычных чисел, чем это предусматривает sprintf()
- Выровнять результат слева. По умолчанию используется выравнивание справа. Этот флаг не действует без указания ширины поля
Ширина поля является строкой десятичных цифр, представляющих минимальную ширину. По умолчанию использует столько символов, сколько необходимо, основываясь на оставшейся части спецификации. Значения, меньшие ширины поля, дополняются пробелами слева (или справа, если указан флаг '-').

Точность слева состоит из символа # и строки десятичных цифр. Она указывает минимальное число цифр, которые должны быть слева от десятичного символа-разделителя дробной части[141]; если преобразованное значение меньше этого, результат выравнивается символом числового заполнения. По умолчанию используется пробел, однако для его изменения можно использовать флаг =. Символы группировки не включаются в общий счет.

Наконец, точность справа состоит из символа '.' и строки десятичных цифр. Она указывает, с каким числом значащих цифр округлить значение до форматирования. По умолчанию используются поля frac_digits и int_frac_digits в struct lconv. Если это значение равно 0, десятичная точка не выводится.

strfmon() возвращает число символов, помещенных в буфер, не включая завершающий нулевой байт. Если недостаточно места, функция возвращает -1 и устанавливает errno в E2BIG.

Помимо strfmon(), POSIX (но не ISO С) предусматривает специальный флаг — символ одинарной кавычки, ' — для форматов printf() %i, %d, %u, %f, %F, %g и %G. В локалях, имеющих разделитель тысяч, этот флаг добавляет и его. Следующая простая программа, ch13-quoteflag.c, демонстрирует вывод:

/* ch13-quoteflag.c --- демонстрация флага кавычки printf */

#include <stdio.h>

#include <locale.h>


int main(void) {

 setlocale(LC_ALL, ""); /* Это нужно, иначе не будет работать */

 printf("%'d\n", 1234567);

return 0;

}

Вот что происходит для двух различных локалей: в одной есть разделитель тысяч, в другой нет:

$ LC_ALL=C ch13-quoteflag /* Обычное окружение без разделителя */

1234567

$ LC_ALL=en_US ch13-quoteflag /* Локаль с разделителем (англ.) */

1,234,567

На время написания лишь GNU/Linux и Solaris поддерживают флаг '. Дважды проверьте справочную страницу printf(3) на своей системе.

13.2.6. Пример: форматирование числовых значений в gawk

gawk реализует свои собственные версии функций printf() и sprintf(). Для полного использования локали gawk должен поддерживать флаг ', как в С. Следующий фрагмент из файла builtin.c в gawk 3.1.4 показывает, как gawk использует struct lconv для числового форматирования:

1  case 'd':

2  case 'i':

3   ...

4   tmpval = force_number(arg);

5

6   ...

7   uval = (uintmax_t)tmpval;

8   ...

9   ii = jj = 0;

10  do {

11   *--cp = (char)('0' + uval % 10);

12 #ifdef HAVE_LOCALE_H

13   if (quote_flag && loc.grouping[ii] && ++jj == loc.grouping[ii]) {

14    *--cp = loc.thousands_sep[0]; /* XXX - предположение, что это один символ */

15    if (loc.grouping[ii+1] == 0)

16     jj = 0; /* продолжить использовать текущий val в loc.grouping [ii] */

17    else if (loc.grouping[ii+1] == CHAR_MAX)

18     quote_flag = FALSE;

19    else {

20     ii++;

21     jj = 0;

22    }

23   }

24 #endif

25   uval /= 10;

26  } while (uval > 0);

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

Переменная loc, используемая в строках 13–17, представляет struct lconv. Она инициализируется в main(). Здесь для нас интерес представляет loc.thousands_sep, который является символом разделителя тысяч, и loc.grouping, который является массивом, описывающим число цифр между разделителями. Нулевой элемент означает «использовать для всех последующих цифр значение предыдущего элемента», а значение CHAR_MAX означает «прекратить вставку разделителей тысяч».

С таким введением, давайте посмотрим на код. Строка 7 устанавливает uval, которая является беззнаковой версией форматируемого значения. ii и jj отслеживают положение в loc.grouping и число цифр в текущей группе, которые были преобразованы, соответственно[142]. quote_flag равен true, когда в спецификации преобразования был отмечен символ '.

Цикл do-while генерирует символы цифр в обратном порядке, заполняя буфер с конца к началу. Каждая цифра создается в строке 11. Затем строка 25 делится на 10 путем смещения значения вправо на одну десятичную цифру.

Нас интересуют строки 12–24. Эта работа осуществляется только на системе, поддерживающей локали, на что указывает наличие заголовочного файла <locale.h>. Именованная константа HAVE_LOCALE в такой системе будет равна true[143].

Когда условие в строке 13 истинно, настало время добавить символ разделителя тысяч. Это условие можно прочесть как «если требуется группировка и текущее положение в loc.grouping указывает нужное для группировки количество и текущее число цифр равно группируемому количеству». Если это условие истинно, строка 14 добавляет символ разделителя тысяч. Комментарий обращает внимание на предположение, которое, вероятно, истинно, но которое может вновь появиться позже. ('XXX' является традиционным способом выделения опасного или сомнительного кода. Его легко отыскать, и он весьма заметен для читателя кода.)

После использования текущего положения в loc.grouping строки 15–22 заглядывают в значение в следующем положении. Если это 0, продолжает использоваться значение текущего положения. Мы указываем на это, восстанавливая 0 в jj (строка 16). С другой стороны, если в следующем положении CHAR_MAX, группировка должна быть прекращена, и строка 18 убирает ее, устанавливая quote_flag в false. В противном случае, следующее значение является значением группировки, поэтому строка 20 восстанавливает 0 в jj, а строка 21 увеличивает значение ii.

Это низкоуровневый, подробный код. Однако, поняв один раз, как представляется информация в struct lconv, код читать просто (и его было просто писать).

13.2.7. Форматирование значений даты и времени: ctime() и strftime()

В разделе 6.1 «Времена и даты» описаны функции для получения и форматирования значений времени и даты. Функция strftime() также может использовать локаль, если setlocale() была вызвана должным образом. Это демонстрирует следующая простая программа, ch13-times.с:

/* ch13-times.c --- демонстрация времени на основе локали */

#include <stdio.h>

#include <locale.h>

#include <time.h>


int main(void) {

 char buf[100];

 time_t now;

 struct tm *curtime;


 setlocale(LC_ALL, "");

 time(&now);

 curtime = localtime(&now);

 (void)strftime(buf, sizeof buf,

  "It is now %A, %B %d, %Y, %I:%M %p", curtime);

 printf("%s\n", buf);

 printf("ctime() says: %s", ctime(&now));

 exit(0);

}

При запуске программы мы видим, что результатыstrftime() в самом деле варьируют, тогда как результаты ctime() — нет:

$ LC_ALL=en_US ch13-times /* Время в Соединенных Штатах */

It is now Friday, July 11, 2003, 10:35 AM

ctime() says: Fri Jul 11 10:35:55 2003

$ LC_ALL=it_IT ch13-times /* Время в Италии */

It is now venerdi, luglio 11, 2003, 10:36

ctime() says: Fri Jul 11 10:36:00 2003

$ LC_ALL=fr_FR ch13-times /* Время во Франции */

It is now vendredi, juillet 11, 2003, 10:36

ctime() says: Fri Jul 11 10:36:05 2003

Причина отсутствия изменений в том, что ctime()asctime(), на которой основана ctime()) является традиционным интерфейсом; он существует для поддержки старого кода, strftime(), будучи более новым интерфейсом (первоначально разработанным для C89), свободен использовать локали.

13.2.8. Другие данные локали: nl_langinfo()

Хотя ранее мы сказали, что API catgets() трудно использовать, одна часть этого API обычно полезна: nl_langinfo(). Она предоставляет дополнительные связанные с локалью сведения, помимо тех, которые доступны из struct lconv:

#include <nl_types.h>

#include <langinfo.h>


char *nl_langinfo(nl_item item);

Заголовочный файл <nl_types.h> определяет тип nl_item. (Это скорее всего int или enum.) Параметр item является одной из именованных констант, определенных в <langinfo.h>. Возвращаемое значение является строкой, которую можно при необходимости использовать либо непосредственно, либо в качестве форматирующей строки для strftime().

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


Таблица 13.3. Значения элементов для nl_langinfo()

Элемент Категория Значение
ABDAY_1, …, ABDAY_7 LC_TIME Сокращенные названия дней недели. Воскресенье является днем 1
ABMON_1, …, ABMON_12 LC_TIME Сокращенные названия месяцев
ALT_DIGITS LC_TIME Альтернативные символы для цифр; см. текст
AM_STR, PM_STR LC_TIME Обозначения a.m/p.m. для локали.
CODESET LC_TYPE Имя кодовой страницы для локали, т.е. использующиеся набор символов и кодировка
CRNCYSTR LC_MONETARY Символ местной валюты, описанный ниже
DAY_1, …, DAY_7 LC_TIME Названия дней недели. Воскресенье является днем 1
D_FMT LC_TIME Формат даты
D_T_FMT LC_TIME Формат даты и времени
ERA_D_FMT LC_TIME Формат даты эры.
ERA_D_T_FMT LC_TIME Формат даты и времени эры.
ERA_T_FMT LC_TIME Формат времени эры.
ERA LC_TIME Сегменты описания эры, см. текст.
MON_1, …, MON_12 LC_TIME Названия месяцев.
RADIXCHAR LC_NUMERIC Символ системы счисления. Для базы 10 это символ точки в десятичной дроби.
THOUSEP LC_NUMERIC Символ-разделитель тысяч
T_FMT_AMPM LC_TIME Формат времени в записи a.m/p.m.
T_FMT LC_TIME Формат времени.
YESEXPR, NOEXPR LC_MESSAGES Строка, представляющая положительный и отрицательный ответы.
Эра является определенным временем в истории. Поскольку она имеет отношение к датам и временам, она имеет наибольший смысл в странах, управляемых императорами и династиями.[144]

Спецификации эр POSIX могут определять эры ранее 1 г. н.э. В таких случаях у начальной даты большее абсолютное числовое значение, чем у конечной даты. Например, Александр Великий правил с 336 г. до н.э. по 323 г до н.э.

Значение, возвращенное 'nl_langinfo(ERA)', если оно не равно NULL, состоит из одной или более спецификаций эр. Каждая спецификация отделена от следующей символом ';'. Компоненты спецификации каждой эры отделяются друг от друга символом ':'. Компоненты описаны в табл. 13.4.


Таблица 13.4. Компоненты спецификации эры

Компонент Значение
Направление Символы '+' или '-'. '+' означает, что эра отсчитывается от численно меньшего года к численно большему году, а '-' означает обратный порядок
Смешение Ближайший к дате начала эры год
Дата начала Дата начала эры в виде 'гггг/мм/дд'. Это соответственно год, месяц и день. Годы до н.э используют для гггг отрицательные значения
Дата конца Дата завершения эры в том же самом виде. Допустимы два дополнительных вида: -* означает «начало времени», а +* означает «конец времени»
Название эры Название эры, соответствующее спецификации преобразования %EC функции strftime()
Формат эры Формат года в пределах эры, соответствующий спецификации преобразования %EY функции strftime()
Значение ALT_DIGITS также нуждается в некотором объяснении. Некоторые локали предоставляют «альтернативные цифры». (Рассмотрите арабский язык, в котором используется десятичная система счисления, но изображения для цифр 0–9 другие. Или рассмотрите гипотетическую локаль «Древнего Рима», использующую римские цифры.) Они появляются, например, в различных спецификациях преобразования %OC в функции strftime(). Возвращаемое значение для 'nl_langinfo(ALT_DIGITS)' является разделяемым точками с запятой списком строк символов для альтернативных цифр. Первая должна использоваться для 0, следующая для 1 и т.д. POSIX утверждает, что могут быть предоставлены до 100 альтернативных символов. Сущность в том, чтобы избежать ограничения локалей использованием символов цифр ASCII, когда у локали есть собственная система счисления.

Наконец, 'nl_langinfo(CRNCYSTR)' возвращает символ местной валюты. Первый символ возвращаемого значения, если это '-', '+' или '.', указывает, как должен использоваться символ:

Символ должен быть перед значением.

Символ должен быть после значения.

Символ должен заменить символ основания (разделитель десятичной дроби).

13.3. Динамический перевод сообщений программ

Только что освещенные интерфейсы стандартной библиотеки С решают простые части проблемы локализации. Для денежных, числовых значений, значений времени и даты, также, как для проблем сортировки строк, применяется управление посредством таблиц специфичных для локали данных (таких, как списки названий месяцев и дней).

Однако, большая часть взаимодействия пользователя с текстовой программой осуществляется в виде выводимых сообщений, таких, как приглашения или сообщения об ошибках. Проблема заключается в необходимости избежания множества версий одной и той же программы, которые отличаются лишь содержанием строк сообщений. Решением де-факто в мире GNU является GNU gettext. (GNU программы сталкиваются с подобными проблемами с элементами меню; обычно у каждого большого инструментария пользовательского интерфейса свой способ решения этой проблемы.)

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

13.3.1. Установка текстового домена: textdomain()

Законченное приложение может содержать множество компонентов: отдельные исполняемые файлы, написанные на С или C++ или на языках сценариев, которые также могут получить доступ к возможностям gettext, таких, как gawk или оболочка Bash Все компоненты приложения разделяют один и тот же текстовый домен, который является строкой, уникально идентифицирующей приложение. (Примерами могут быть «gawk» или «coreutils»; первое является простой программой, а последнее — целым набором программ.) Текстовый домен устанавливается функцией textdomain():

#include <libintl.h> /* GLIBC */


char* textdomain(const char *domainname)

Каждый компонент должен вызывать эту функцию со строкой, указывающей на текстовый домен, в составе первоначальной инициализации в main(). Возвращаемое значение является текущим текстовым доменом. Если аргумент domainname равен NULL, возвращается текущий домен; в противном случае, он устанавливается в указанное значение, а последнее возвращается. Возвращаемое значение NULL указывает на какую-нибудь разновидность ошибки.

Если текстовый домен не установлен с помощью textdomain(), по умолчанию используется «messages».

13.3.2. Перевод сообщений: gettext()

Следующим после установки текстового домена шагом является использование функции gettext() (или ее разновидности) для каждой строки, которая должна быть переведена. Несколько функций предоставляют службы перевода:

#include <libintl.h> /* GLIBC */


char *gettext(const char *msgid);

char *dgettext(const char *domainname, const char *msgid);

char *dcgettext(const char *domainname, const char *msgid, int category);

Аргументы, используемые в этих функциях, следующие:

const char *msgid

Переводимая строка. Она действует в качестве ключа к базе данных переводов.

const char *domainname

Текстовый домен, из которого нужно получить перевод. Таким образом, хотя main() вызвала textdomain() для установки собственного домена приложения, сообщения могут быть получены из других текстовых доменов. (Это наиболее применимо к сообщениям, которые могли бы быть, например, в текстовом домене библиотеки от третьей стороны.)

int category

Одна из описанных ранее категорий доменов (LC_TIME и т.п.). Доменом по умолчанию является то, что было раньше установлено с помощью textdomain()messages», если textdomain() никогда не вызывалась). Категорией по умолчанию является LC_MESSAGES. Предположим, main() делает следующий вызов:

textdomain("killerapp");

Тогда 'gettext("my message")' эквивалентно 'dgettext("killerapp", "my message")'. Обе функции, в свою очередь, эквивалентны 'dcgettext("killerapp", "my message", LC_MESSAGES)'.

В 99,9% времени бывает нужно использовать gettext(). Однако, другие функции обеспечивают гибкость при работе с другими текстовыми доменами или категориями локалей. Скорее всего, эта гибкость потребуется при программировании библиотек, поскольку автономная библиотека почти наверняка будет использовать свой собственный текстовый домен.

Все функции возвращают строки. Строка является либо переводом данного msgid, либо, если перевода не существует, первоначальной строкой. Таким образом, всегда имеется какой-нибудь вывод, даже если это первоначальное сообщение (предположительно на английском). Например:

/* Каноническая первая программа, локализованная версия. */

#include <stdio.h>

#include <locale.h>

#include <libintl.h>


int main(void) {

 setlocale(LC_ALL, "");

 printf("%s\n", gettext("hello, world"));

 return 0;

}

Хотя сообщение является простой строкой, мы не используем ее непосредственно в форматирующей строке printf(), поскольку в общем перевод может содержать символы %.

Вскоре, в разделе 13.3.4 «Упрощение использования gettext()», мы увидим, как облегчить использование gettext() в крупномасштабных, реальных программах.

13.3.3. Работа с множественными числами: ngettext()

Перевод во множественном числе доставляет дополнительные трудности. Простой код мог бы выглядеть примерно так:

printf("%d word%s misspelled\n", nwords, nwords > 1 ? "s" : "");

/* или */

printf("%d %s misspelled\n", nwords, nwords == 1 ? "word" : "words").

Это подходит для английского языка, но перевод становится трудным. Во-первых, во многих языках множественное число не образуется с такой же легкостью, как в английском (добавлением суффикса s для большинства слов). Во-вторых, во многих языках, особенно в Восточной Европе, имеются несколько форм множественного числа, каждая из которых указывает на то, сколько объектов обозначает форма. Соответственно даже код наподобие следующего не будет достаточным:

if (nwords == l)

 printf("one word misspelled\n");

else

 printf("%d words misspelled\n", nwords);

Решением является параллельный набор процедур специально для форматирования множественных значений:

#include <libintl.h> /* GLIBC */


char *ngettext(const char *msgid, const char *msgid_plural,

 unsigned long int n);

char *dngettext(const char *domainname, const char *msgid,

 const char *msgid_plural, unsigned long int n);

char *dcngettext(const char *domainname, const char *nmgid,

 const char *msgid_plural, unsigned long int n,

 int category)

Помимо первоначального аргумента msgid, эти функции принимают дополнительные аргументы:

const char *msgid_plural

Строка по умолчанию для использования в качестве множественного числа. Вскоре будут примеры.

unsigned long int n

Число имеющихся элементов.

Список сообщений каждой локали указывает, как переводить множественные числа.[145] Функция ngettext() (и ее варианты) проверяет n и на основании спецификации в списке сообщений возвращает соответствующий перевод msgid. Если в списке нет перевода для msgid, или находясь в локали «С», ngettext() возвращает msgid, если 'n == 1'; в противном случае она возвращает msgid_plural. Таким образом, наш пример ошибочных слов выглядит следующим образом:

printf("%s\n", ngettext("%d word misspelled", "%d words misspelled", nwords), nwords);

Обратите внимание, что nwords должен быть передан ngettext() для выбора форматирующей строки, а затем printf() для форматирования. Вдобавок, будьте осмотрительны и не используйте макрос или выражение, значение которого каждый раз изменяется, как в случае 'n++'! Такое может случиться, если вы осуществляете глобальное редактирование, добавляя вызовы ngettext() и не обращая на это внимания.

13.3.4. Упрощение использования gettext()

Вызов gettext() в исходном коде программы служит двум целям. Во-первых, он осуществляет перевод во время исполнения, что является в конце концов главным. Однако, он служит также для отметки строк, которые нужно перевести. Утилита xgettext читает исходный код программы и извлекает все оригинальные строки, которые нужно перевести. (Далее в главе мы кратко рассмотрим это.)

Рассмотрим все-таки случай, когда статические строки не используются непосредственно:

static char *copyrights[] = {

 "Copyright 2004, Jane Programmer",

 "Permission is granted ...",

 /* ... Здесь куча легальностей */

 NULL

};


void copyright(void) {

 int i;

 for (i = 0; copyrights[i] != NULL, i++)

  printf("%s\n", gettext(copyrights[i]));

}

Здесь мы хотели бы иметь возможность вывести переводы строк об авторских правах, если они доступны. Однако, как извлекающее устройство xgettext предполагает найти эти строки? Мы не можем заключить их в вызовы gettext(), поскольку это не будет работать во время компиляции:

/* ПЛОХОЙ КОД: не будет компилироваться */

static char *copyrights[] = {

 gettext("Copyright 2004, Jane Programmer"),

 gettext("Permission is granted ..."),

 /* ... Здесь куча легальностей */

 NULL

};

13.3.4.1. Переносимые программы: "gettext.h"

Здесь мы предполагаем, что вы хотите написать программу, которая может использоваться вместе с библиотекой GNU gettext на любой системе Unix, а не только GNU/Linux. Следующий раздел описывает, что сделать для программ только для GNU/Linux.

Пометка строк включает два шага. Первый заключается в использовании вспомогательного заголовка gettext.h, который поставляется с дистрибутивом GNU gettext. Этот файл обрабатывает несколько проблем переносимости и компиляции, упрощая использование gettext() в ваших собственных программах:

#define ENABLELNLS 1 /* ENABLE_NLS должен быть true, чтобы gettext() работала */

#include "gettext.h" /* Вместо <libintl.h> */

Если макрос ENABLE_NLS не определен[146] или установлен в ноль, gettext.h развертывает вызовы gettext() в первый аргумент. Это делает возможным перенос кода, использующего gettext(), на системы, в которых не установлены ни GNU gettext, ни собственная их версия. Помимо прочего, этот заголовочный файл определяет следующий макрос:

/* Вызов псевдофункции, который служит в качестве маркера для

   автоматического извлечения сообщений, но не осуществляющий вызов

   gettext(). Перевод времени исполнения осуществляется в другом

   месте кода. Аргумент String должен быть символической строкой.

   Сцепленные строки и другие строковые выражения не будут работать.

   Разворачивание макроса не параметризовано, так что он подходит для

   инициализации статических переменных 'char[]' или 'const char[]'. */

#define gettext_noop(String) String

Комментарий самодостаточен. С помощью этого макроса мы можем теперь перейти ко второму шагу. Мы перепишем код следующим образом:

#define ENABLE_NLS 1

#include "gettext.h"


static char copyrights[] =

 gettext_noop("Copyright 2004, Jane Programmer\n"

 "Permission is granted ...\n"

 /* ... Здесь куча легальностей */

 "So there.");


void copyright(void) {

 printf("%s\n", gettext(copyrights));

}

Обратите внимание, что мы сделали два изменения. Во-первых, copyrights теперь является одной длинной строкой, созданной с использованием возможности конкатенации строк стандартного C. Эта простая строка затем включена в вызов gettext_noop(). Нам нужна одна строка, чтобы легальности могли быть переведены в виде одного элемента

Второе изменение заключается в непосредственном выводе перевода в виде одной строки в copyright().

К этому времени вы, возможно, думаете: «Вот здорово, набирать каждый раз 'gettext(...)' довольно неприятно». Ну, вы правы. Это не только создает лишнюю работу по набиванию, но также и затрудняет чтение исходного кода. Соответственно, когда вы используете заголовочный файл gettext.h, руководство GNU gettext рекомендует включить два других макроса с именами _() и N_() следующим образом:

#define ENABLE_NLS 1

#include "gettext.h"

#define _(msgid) gettext(msgid)

#define N_(msgid) msgid

Такой подход снижает накладные расходы по использованию gettext() всего лишь тремя дополнительными символами для переводимой строковой константы и всего лишь четырьмя символами для статических строк:

#include <stdio.h>

#define ENABLE_NLS 1

#include "gettext.h"

#define _(msgid) gettext(msgid)

#define N_(msgid) msgid

...

static char copyrights[] =

 N_("Copyright 2004, Jane Programmer\n"

 "Permission is granted ...\n"

 /* ... Здесь куча легальностей */

 "So there.");


void copyright(void) {

 printf("%s\n", gettext(copyrights));

}


int main(void) {

 setlocale(LC_ALL, ""); /* gettext.h gets <locale.h> for us too */

 printf("%s\n", _("hello, world"));

 copyright();

 exit(0);

}

Эти макросы скромны, и на практике все GNU программы, использующие GNU gettext, следуют этому соглашению. Если вы собираетесь использовать GNU gettext, вам тоже нужно следовать этому соглашению.

13.3.4.2. Только GLIBC: <libintl.h>

Для программ, которые будут использоваться лишь на системах с GLIBC, использование заголовочных файлов и макросов похоже, но проще:

#include <stdio.h>

#include <libintl.h>

#define _(msgid) gettext(msgid)

#define N_(msgid) msgid

/* ... все остальное то же ... */

Как мы видели ранее, заголовочный файл <libintl.h> объявляет gettext() и другие функции. Вам все равно нужно определять _() и N_(), но не нужно беспокоиться о ENABLE_NLS или включении с исходным кодом вашей программы файла gettext.h.

13.3.5. Перестановка порядка слов с помощью printf()

Иногда при переводах порядок слов, естественный для английского языка, не подходит в других языках. Например, на английском прилагательные идут перед определяемыми существительными, а на многих других языках — после. Таким образом, следующий код представляет проблему:

char *animal_color, *animal;


if (...) {

 animal_color = _("brown");

 animal = _("cat");

} else if (...) {

 ...

} else {

 ...

}

printf(_("the %s %s looks at you enquiringly.\n"), animal_color, color);

Здесь форматирующая строка, animal_color и animal неудачно включены в вызов gettext(). Однако, после перевода утверждение будет неверным, поскольку порядок аргументов не может быть изменен во время исполнения.

Чтобы обойти это, версия семейства printf() POSIX (но не ISO С) допускает использовать в описателе формата указатель положения. Он принимает форму десятичного числа, за которым следует символ $, сразу после начального символа %. Например printf("%2$s, %1s\n", "world", "hello");

Указатель положения обозначает аргумент из списка, который следует использовать, отсчет начинается с 1 и не включает саму форматирующую строку. Этот пример выводит знаменитое сообщение 'hello, world' в правильном порядке.

GLIBC и Solaris реализуют эту возможность. Поскольку это часть POSIX, если printf() вашего поставщика Unix не реализует ее, она вскоре должна появиться.

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

• Форма с указателем положения не может смешиваться с формой без нее. Другими словами, или каждый указатель формата включает указатель положения, или ни один его не включает. Конечно, %% может использоваться всегда.

• Если в форматирующей строке используется N-й аргумент, в этой строке должны использоваться также все аргументы до N. Соответственно, следующее неверно printf("%3$s %1$s\n", "hello", "cruel", "world");

• Ссылка на определенный аргумент может быть сделана указателем положения несколько раз. Не позиционные спецификаторы формата всегда движутся через список аргументов последовательно.

Эта возможность не предназначена для непосредственного использования программистами приложений, она скорее для переводчиков. Например, перевод предыдущей форматирующей строки, "The %s %s looks at you enquiringly.\n", на французский мог бы быть:

"Le %2$s %1$s te regarde d'un aire interrogateur.\n"

(Даже этот перевод не совершенен: артикль «Le» имеет род. Подготовка программы к переводу трудная задача!)

13.3.6. Тестирование переводов в персональном каталоге

Коллекция сообщений в программе называется списком сообщений (message catalog). Этот термин применяется также к каждому из переводов сообщений на другой язык. Когда программа установлена, каждый перевод также устанавливается в стандартное место, где gettext() может во время исполнения найти нужный перевод.

Может оказаться полезным разместить переводы не в стандартном, а в другом каталоге, особенно для тестирования программы. Особенно на больших системах, у обычного пользователя может не быть необходимых разрешений для установки файлов в системные каталоги. Функция bindtextdomain() дает gettext() альтернативное место для поиска переводов:

#include <libintl.h> /* GLIBC */


char *bindtextdomain(const char *domainname,

const char *dirname);

Полезные каталоги включают '.' для текущего каталога и /tmp. Может оказаться удобным также получить каталог из переменной окружения, подобно этому:

char *td_dir;

setlocale(LC_ALL, "");

textdomain("killerapp");

if ((td_dir = getenv("KILLERAPP_TD_DIR")) != NULL)

 bindtextdomain("killerapp", td_dir);

bindtextdomain() должна быть вызвана до вызовов любой из функций из семейства gettext(). Мы увидим пример ее использования в разделе 13.3.8 «Создание переводов»

13.3.7. Подготовка интернационализированных программ

К настоящему моменту мы рассмотрели все компоненты, из которых состоит интернационализированная программа. Данный раздел подводит итоги.

1. Включите в свое приложение заголовочный файл gettext.h, добавьте определения для макросов _() и N_() в заголовочный файл, который включается во все ваши исходные файлы на С. Не забудьте определить именованную константу ENABLE_NLS.

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

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

4. При тестировании свяжите текстовый домен с определенным каталогом при помощи bindtextdomain().

5. Используйте соответствующим образом strfmon(), strftime() и флаг '. Если нужна другая информация о локали, используйте nl_langinfo(), особенно в сочетании с strftime().

6. Пометьте все строки, которые должны быть переведены, соответствующими вызовами _() или N_().

Хотя некоторые не следует так помечать. Например, если вы используете getopt_long() (см. раздел 2.1.2 «Длинные опции GNU»), вы, вероятно, не захотите, чтобы имена длинных опций были помечены для перевода. Не требуют перевода и простые форматирующие строки наподобие "%d %d\n", также как отладочные сообщения.

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

8. Упростите жизнь для своих переводчиков, используя строки с полными предложениями вместо замены слов с помощью %s и ?:. Например:

if (/* возникла ошибка */) { /* ВЕРНО */

 /* Использовать несколько строк для упрощения перевода. */

 if (input_type == INPUT_FILE)

  fprintf(stderr, _("%s: cannot read file: %s\n"),

   argv[0], strerror(errno));

 else

  fprintf(stderr, _("%s: cannot read pipe: %s\n"),

   argv[0], strerror(errno));

Это лучше, чем

if (/* возникла ошибка */) { /* НЕВЕРНО */

 fprintf(stderr, _("%s: cannot read %s: %s\n"), argv[0],

 input_type == INPUT_FILE ? _("file") : _("pipe"),

 strerror(errno));

}

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

13.3.8. Создание переводов

После интернационализации программы необходимо подготовить переводы. Это осуществляется с помощью нескольких инструментов уровня оболочки. Мы начнем с интернационализированной версии ch06-echodate.c из раздела 6.1.4 «Преобразование разложенного времени в time_t»:

/* ch13-echodate.c --- демонстрация переводов */

#include <stdio.h>

#include <time.h>

#include <locale.h>

#define ENABLE_NLS 1

#include "gettext.h"

#define _(msgid) gettext(msgid)

#define N_(msgid) msgid


int main (void) {

 struct tm tm;

 time_t then;


 setlocale(LC_ALL, "");

 bindtextdomain("echodate", ".");

 textdomain("echodate");


 printf("%s", _("Enter a Date/time as YYYY/MM/DD HH:MM:SS : "));

 scanf("%d/%d/%d %d:%d:%d",

  &tm.tm_year, &tm.tm_mon, &tm.tm_mday,

  &tm.tm_hour, &tm.tm_min, &tm.tm_sec);


 /* Проверка ошибок для краткости опущена. */

 tm.tm_year -= 1900;

 tm.tm_mon -= 1;

 tm.tm_isdst = -1; /* О летнем времени ничего не известно */


 then = mktime(&tm);

 printf(_("Got: %s"), ctime(&then));

 exit(0);

}

Мы намеренно использовали "gettext.h", а не <gettext.h>. Если наше приложение поставляется с отдельной копией библиотеки gettext, тогда "gettext.h" найдет ее, избежав использования системной копии. С другой стороны, если имеется лишь системная копия, она будет найдена, если локальной копии нет. Общеизвестно, что ситуация усложнена фактом наличия на системах Solaris библиотеки gettext, которая не имеет всех возможностей версии GNU.

Переходя к созданию переводов, первым шагом является извлечение переводимых строк. Это осуществляется программой xgettext:

$ xgettext --keyword=_ --keyword=N_ \

> --default-domain=echodate ch13-echodate.с

Опции --keyword сообщает xgettext, что нужно искать макросы _() и N_(). Программа уже знает, как извлекать строки из gettext() и ее вариантов, а также из gettext_noop().

Вывод xgettext называется переносимым объектным файлом. Имя файла по умолчанию messages.ро, что соответствует текстовому домену по умолчанию "messages". Опция --default-domain обозначает текстовый домен для использования в имени выходного файла. В данном случае, файл назван echodate.ро. Вот его содержание:

# SOME DESCRIPTIVE TITLE. /* Шаблон, нужно отредактировать */

# Copyright (С) YEAR THE PACKAGE'S COPYRIGHT HOLDER

# This file is distributed under the same license as the PACKAGE package.

# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.

#

#, fuzzy

msgid "" /* Подробная информация */

msgstr "" /* Заполняет каждый переводчик */

"Project-Id-Version: PACKAGE VERSION\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2003-07-14 18:46-0700\n"

"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"

"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"

"Language-Team: LANGUAGE <LL@li.org>\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=CHARSET\n"

"Content-Transfer-Encoding: 8bit\n"


#: ch13-echodate.c:19 /* Местоположение сообщения */

msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : " /* Оригинальное

                                                       сообщение */

msgstr "" /* Здесь перевод */


#: ch13-echodate.с:32 /* To же самое для каждого сообщения */

#, с-format

msgid "Got: %s"

msgstr ""

Этот первоначальный файл используется повторно для каждого перевода. Таким образом, это шаблон для переводов, и по соглашению, для отображения этого факта он должен быть переименован с расширением .pot (portable object template — переносимый объектный шаблон):

$ mv echodate.ро echodate.pot

He владея свободно несколькими языками, мы решили перевести сообщения на свинский латинский. Следующим шагом является создание перевода. Это осуществляется копированием файла шаблона и добавлением к новой копии перевода:

$ cp echodate.pot piglat.po

$ vi piglat.po /* Добавить переводы, используя любимый редактор */

Имя по соглашению должно быть язык.po, где язык является стандартным международным сокращением из двух или трех букв для обозначения языка. Иногда используется форма язык_страна.po: например, pt_BR.po для португальского в Бразилии. Поскольку свинский латинский не является настоящим языком, мы назвали файл piglat.ро.[147] Вот содержание после добавления перевода:

# echodate translations into pig Latin

# Copyright (C) 2004 Prentice-Hall

# This file is distributed under the same license as the echodate package.

# Arnold Robbins <arnold@example.com> 2004

#

#, fuzzy

msgid ""

msgstr ""

"Project-Id-Version: echodate 1.0\n"

"Report-Msgid-Bugs-To: arnold@example.com\n"

"POT-Creation-Date: 2003-07-14 18:46-0700\n"

"PO-Revision-Date: 2003-07-14 19:00+8\n"

"Last-Translator: Arnold Robbins <arnold@example.com>\n"

"Language-Team: Pig Latin <piglat@li.example.org>\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=ASCII\n"

"Content-Transfer-Encoding: 8bit\n"


#: ch13-echodate.с:19

msgid "Enter a Date/time as YYYY/MM/DD HH:MM:SS : "

msgstr "Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : "


#: ch13-echodate.c:32

#, c-format

msgid "Got: %s"

msgstr "Otgay: %s"

Хотя можно было бы произвести линейный поиск в переносимом объектном файле, такой поиск был бы медленным. Например, в gawk имеется примерно 350 отдельных сообщений, а в GNU Coreutils — свыше 670. Линейный поиск в файле с сотнями сообщений был бы заметно медленным. Поэтому GNU gettext использует для быстрого поиска сообщений двоичный формат. Сравнение осуществляет msgfmt, выдавая объектный файл сообщений:

$ msgfmt piglat.po -о piglat.mo

При сопровождении программы изменяются строки, используемые программой: добавляются новые, другие удаляются или изменяются. По крайней мере, может измениться положение строки в исходном файле. Таким образом, файлы переводов .ро, вероятно, устареют. Программа msgmerge объединяет старые файлы переводов с новым файлом .pot. Затем результат может быть обновлен. Этот пример выполняет объединение и повторное компилирование:

$ msgmerge piglat.po echodate.pot -o piglat.new.po /* Объединить файлы */

$ mv piglat.new.po piglat.po /* Переименовать результат */

$ vi piglat.po /* Модернизировать перевод */

$ msgfmt piglat.po -o piglat.mo /* Восстановить файл .mo */

Откомпилированные файлы .mo помещаются в файл base/locale/category/textdomain.mo. На системах GNU/Linux base является /usr/share/locale. locale является обозначением языка, например, 'es', 'fr' и т.д. category является категорией локали; для сообщений это LC_MESSAGES. textdomain является текстовым доменом программы, в нашем случае это echodate. В качестве реального примера в /usr/share/locale/es/LC_MESSAGES/coreutils.mo находится перевод GNU Coreutils на испанский.

Функция bindtextdomain() изменяет в местоположении часть base. В ch13-echodate.c мы меняем ее на '.'. Таким образом, нужно создать соответствующие каталоги и поместить туда перевод на свинский латинский:

$ mkdir -р en_US/LC_MESSAGES /* Нужно использовать реальную локаль */

$ cp piglat.mo en_US/LC_MESSAGES/echodate.mo /* Поместить файл в нужное место */

Должна использоваться реальная локаль[148]; мы «притворяемся» использующими "en_US". Разместив перевод, устанавливаем соответствующим образом LC_ALL, скрещиваем пальцы и запускаем программу:

$ LC_ALL=en_US ch13-echodate /* Запуск программы */

Enteray A Ateday/imetay asay YYYY/MM/DD HH:MM:SS : 2003/07/14 21:19:26

Otgay: Mon Jul 14 21:19:26 2003

Последнюю версию GNU gettext можно найти в каталоге дистрибутива GNU gettext.[149]

Этот раздел лишь слегка коснулся поверхности процесса локализации. GNU gettext предоставляет множество инструментов для работы с переводами, и в особенности для облегчения поддержания современности переводов по мере развития исходного кода программы. Процесс ручного обновления переводов осуществим, но утомителен. Эта задача легко автоматизируется с помощью make; в частности, GNU gettext хорошо интегрируется для обеспечения этой возможности с Autoconf и Automake, снимая с программиста значительный груз по разработке.

Рекомендуем прочесть документацию GNU gettext, чтобы больше узнать как об этих проблемах в частности, так и о GNU gettext в общем.

13.4. Не могли бы вы произнести это для меня по буквам?

В самые ранние дни вычислительной техники различные системы назначали различные соответствия между числовыми значениями и глифами (glyphs) — символами, такими, как буквы, цифры и знаки пунктуации, используемыми для общения с людьми. В конечном счете появились два широко использующихся стандарта: кодировка EBCDIC, используемая IBM и подобными ей мэйнфреймами, и ASCII, использующаяся для всего остального. Сегодня, за исключением мэйнфреймов, ASCII является основой для всех других использующихся наборов символов.

Оригинальный семиразрядный набор символов ASCII достаточен для американского английского и большинства знаков пунктуации и специальных символов (таких, как $, но нет символа для «цента»). Однако, имеется много языков и много стран, которым нужны другие наборы символов. ASCII не оперирует версиями романских символов с надстрочными значками, использующимися в Европе, а во многих азиатских языках тысячи символов. Для устранения этих недостатков были разработаны новые технологии.

Литература по интернационализации изобилует ссылками на три фундаментальных термина. Определив их и взаимоотношения между ними, мы сможем представить общее описание соответствующих функций API С.

Набор символов (character set)

Определение значений, присваиваемых различным целым величинам; например того, что A равно 65. Любой набор символов, использующий более восьми битов на символ, называется многобайтным набором символов.

Представление набора символов (character set encoding)

ASCII использует для представления символов один байт. Таким образом, целое значение хранится само по себе, непосредственно в дисковых файлах. Более современные наборы символов, особенно различные версии Unicode[150], используют для представления символов 16-разрядные или даже 32-разрядные целые значения. Для большинства определенных символов один, два или даже три старших байта целого значения равны нулю, что делает непосредственное хранение таких значений на диске неэффективным. Представление набора символов описывает механизм для преобразования 16- или 32-разрядных значений в последовательности от одного до шести байтов для сохранения на диске таким образом, что в целом наблюдается значительная экономия дисковой памяти.

Язык

Правила данного языка определяют использование набора символов. В частности, правила влияют на сортировку символов. Например, на французском е, é и è все должны находиться между d и f, независимо от назначенных этим символам числовых значений. Различные языки могут назначить (и назначают) одним и тем же глифам различный порядок сортировки.

Со временем для поддержки многобайтных наборов символов были разработаны различные технологии. Вычислительная практика медленно стремится к Unicode и соответствующим его представлениям, но стандартный С и POSIX поддерживают как старые, так и современные технологии. В данном разделе представлен концептуальный обзор различных возможностей. Нам самим не приходилось их использовать, поэтому мы предпочитаем просто познакомить с ними и предоставить ссылки на дополнительную информацию.

13.4.1. Широкие символы

Мы начнем с концепции широких символов (wide character). Широкий символ является целым типом, в котором может храниться любое значение из определенного используемого многобайтного набора символов.

Широкие символы представлены на С типом wchar_t. C99 предоставляет соответствующий тип wint_t, в котором может находиться любое значение, допустимое для wchar_t, а также специальное значение WEOF, аналогичное обычному EOF из <stdio.h>. В заголовочном файле <wchar.h> определены различные типы. Ряд функций, сходных с функциями в <ctype.h>, такие, как iswalnum() и др., определены в заголовочном файле <wctype.h>.

Широкие символы могут быть от 16 до 32 битов размером в зависимости от реализации. Как упоминалось, они нацелены на манипулирование данными в памяти и обычно не хранятся в файлах непосредственно.

Стандарт C предусматривает для широких символов большое число функций и макросов, соответствующих традиционным функциям, работающим с данными char. Например, wprintf(), iswlower() и т.д. Они документированы в справочных страницах GNU/Linux и в книгах по стандартному С.

13.4.2. Представления многобайтных символов

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

Многие описанные кодировкииспользуют для представления многобайтных символов состояния регистра (shift states). Другими словами, в данном потоке байтов значения байтов представляют самих себя до тех пор, пока не встретится специальное управляющее значение. В этот момент интерпретация изменяется в соответствии с текущим состоянием регистра. Таким образом, одно и то же восьмибитовое значение может иметь два значения: одно для обычного состояния, без использования регистра, и другое для использования регистра. Предполагается, что правильно закодированные строки начинаются и заканчиваются с одним и тем же состоянием регистра.

Значительным преимуществом Unicode является то, что его представления являются самокорректирующимися; кодировки не используют состояния регистров, поэтому потеря данных в середине не может повредить последующим закодированным данным.

Первоначальные версии функций преобразования многобайтных символов в широкие и широких в многобайтные поддерживали закрытую копию состояния преобразования (например, состояние регистра, а также все остальное, что могло понадобиться) Такая модель ограничивает использование функции лишь одним видом преобразования в течение жизни программы. Примерами являются mblen() (определение длины многобайтной строки), mbtowc() (преобразование многобайтного символа в широкий), wctomb() (преобразование широкого символа в многобайтный), mbstowcs() (преобразование многобайтной строки в строку широких символов), wcstombs() (преобразование строки широких символов в многобайтную строку).

Новые версии этих процедур называются повторно запускаемыми (restartable). Это означает, что код уровня пользователя сохраняет состояние преобразования в отдельном объекте типа mbstate_t. Соответствующими примерами являются mbrlen(), mbrtowc(), wcrtomb(), mbsrtowcs() и wcsrtombs(). (Обратите внимание на r в их именах, это означает «restartable».)

13.4.3. Языки

Языковые проблемы управляются локалью. Ранее в главе мы уже видели setlocale() POSIX предоставляет продуманный механизм для определения правил, посредством которых работает локаль; некоторые подробности см. в справочной странице GNU/Linux locale(5), а полностью — в самом стандарте POSIX.

Правда в том, что подробности на самом деле не нужны. Вам, как разработчику программ, не нужно беспокоиться о них; как заставить все работать, зависит от разработчиков библиотек. Все, что нужно, это понять концепции и использовать в своем коде соответствующие функции, такие, как strcoll() (см. раздел 13.2.3 «Сравнение строк: strcoll() и strxfrm()»).

Современные системы GLIBC предоставляют отличную поддержку локалей, включая поддерживающие локали процедуры сопоставления регулярных выражений. Например, расширенное регулярное выражение POSIX [[:alpha:]][[:alnum:]]+ соответствует букве, за которой следуют одна или более букв или цифр (алфавитный символ, за которым следуют один или более алфавитно-цифровых символов). Определение того, какие символы соответствуют этим классам, зависит от локали. Например, это регулярное выражение соответствовало бы двум символам '', тогда как регулярное выражение [a-zA-Z][a-A-Zz0-9]+ традиционного, ориентированного на ASCII Unix — скорее всего нет. Классы символов POSIX перечислены в табл. 13.5.


Таблица 13.5. Классы символов регулярных выражений POSIX

Класс Соответствует
[:alnum:] Алфавитно-цифровые символы
[:alpha:] Алфавитные символы
[:blank:] Символы пробела и табуляции.
[:cntrl:] Управляющие символы
[:digit:] Цифровые символы
[:graph:] Символы, являющиеся одновременно печатными и видимыми. (Символ конца строки печатный, но не видимый, тогда как $ является и тем, и другим.)
[:lower:] Строчные алфавитные символы
[:print:] Печатные (не управляющие) символы
[:punct:] Знаки пунктуации (не буквы, цифры, управляющие или пробельные символы)
[:space:] Пробельные символы (такие, как сам пробел, символы табуляции, конца строки и т.д)
[:upper:] Заглавные алфавитные символы
[:xdigit:] Символы из набора abcdefABCDEF0123456789

13.4.4. Заключение

Возможно, вам никогда не придется иметь дело с различными наборами символов и их представлениями. С другой стороны, мир быстро становится «глобальным сообществом», и авторы программ не могут позволить себе быть ограниченными. Следовательно, стоит знать о проблемах интернационализации и наборов символов, а также способах их влияния на поведение вашей системы. По крайней мере, уже один из поставщиков дистрибутивов GNU/Linux устанавливает для систем в Соединенных Штатах локаль по умолчанию en_US.UTF-8.

13.5. Рекомендуемая литература

1. С, A Reference Manual, 5th edition, by Samuel P. Harbison III and Guy L. Steele, Jr., Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.

Мы уже упоминали эту книгу раньше. Она дает точное и исчерпывающее описание развития и использования возможностей стандартной библиотеки С для работы с многобайтными и широкими символами. Это особенно ценно для современных систем, поддерживающих C99, поскольку библиотека была значительно усовершенствована для стандарта С 1999 г.

2. GNU gettext tools, by Ulrich Drepper, Jim Meyering, François Pinard, and Bruno Haible. Это руководство по GNU gettext. На системе GNU/Linux вы можете посмотреть локальную копию через 'info gettext'. Или загрузить и распечатать последнюю версию (по адресу ftp://ftp.gnu.org/gnu/gettext/).

13.6. Резюме

• Интернационализация и локализация программ подпадают под общее название поддержки родного языка. Широко распространенными сокращениями являются i18n, l10n и NLS. Центральным является понятие локали, которая позволяет настраивать набор символов, отображение даты, времени, денежных и числовых величин в соответствии с принятыми для данного языка и в данной стране нормами.

• Использование локали устанавливается с помощью функции setlocale(). Различные категории локали предоставляют доступ к различным видам информации локали. Не использующие локаль программы действуют, как если бы они находились в локали «С», которая выдает типичные для систем Unix до NLS результаты: 7-разрядный ASCII, английские названия месяцев и дней и т.д. Локаль «POSIX» эквивалентна локали «С».

• Сравнение строк с учетом локали осуществляется функцией strcoll() или комбинацией strxfrm() и strcmp(). Возможности библиотеки предоставляют доступ к сведениям о локали (localeconv() и nl_langinfo()), а также к специфического для локали форматирования (strfmon(), strftime() и printf()).

• Обратной стороной получения относящейся к локали информации является вывод сообщений на местном языке. Модель catgets() System V, хотя и стандартизована POSIX, трудна для использования и поэтому не рекомендуется.[151] Вместо этого GNU gettext реализует и расширяет оригинальный замысел Solaris.

• При использовании gettext() оригинальная строка сообщения на английском действует в качестве ключа в двоичном файле перевода, из которого получается перевод строки. Каждое приложение указывает уникальный текстовый домен таким образом, чтобы gettext() могла найти нужный файл с переводом (известный как «список сообщений»). Текстовый домен устанавливается с помощью функции textdomain(). При тестировании или иной надобности местоположение списка сообщений можно изменить с помощью функции bindtextdomain().

• gettext() и ее варианты предоставляют доступ к переводам в различных текстовых доменах или различных категориях локалей. Вдобавок, функция ngettext() и ее варианты дают возможность делать правильные переводы множественных чисел, не перегружая разработчика. Указатель положения в спецификаторе формата printf() дает возможность перевода форматирующих строк, аргументы которых должны выводиться в другом порядке, чем они располагаются в строке.

• На практике GNU программы используют для пометки переводимых строк в исходных файлах заголовочный файл gettext.h и макросы _() и N_(). Такая практика обеспечивает удобочитаемость исходного кода и возможность его поддержки, предоставляя в то же время преимущества интернационализации и локализации.

• GNU gettext предоставляет многочисленные инструменты для создания и управления базами данных переводов (переносимых объектных файлов) и их двоичными эквивалентами (объектными файлами сообщений).

• Наконец, стоит быть в курсе проблем наборов символов и их представлений. Поставщики программного обеспечения не могут больше позволить себе предполагать, что их пользователи хотят работать лишь на одном языке.

Упражнения

1. Поддерживает ли ваша система локали? Если да, какая локаль используется по умолчанию?

2. Просмотрите справочную страницу locale(1), если она у вас есть. Сколько имеется локалей, если вы посчитаете их с помощью 'locale -a | wc -l'?

3. Поэкспериментируйте с ch13-strings.с, ch13-lconv.c, ch13-strfmon.с, ch13-quoteflag.c и ch13-times.c в различных локалях. Какая из найденных локалей самая «необычная» и почему?

4. Возьмите одну из своих программ. Интернационализируйте ее с использованием GNU gettext. Постарайтесь найти кого-нибудь, кто говорит на другом языке, чтобы перевести для вас сообщения. Откомпилируйте перевод и протестируйте его, использовав bindtextdomain(). Какова была реакция вашего переводчика при виде использования перевода?

Глава 14 Расширенные интерфейсы

В данной главе описываются несколько расширенных API. Они сходны по своей природе с описанными ранее в книге или предоставляют дополнительные возможности. Некоторые из них трудно было свободно обсуждать, пока не были освещены предварительные темы.

Порядок представления здесь соответствует порядку глав в первой половине книги. В другом отношении темы не связаны друг с другом. Мы освещаем следующие вопросы: динамическое выделение выровненной памяти; блокировку файлов; ряд функций, работающих со значениями долей секунды; и более развитый набор функций для сохранения и получения произвольных значений данных. Если не указано противное, все API в данной главе включены в стандарт POSIX.

14.1. Выделение выровненной памяти: posix_memalign() и memalign()

Для большинства задач отлично подходят стандартные процедуры выделения памяти — malloc(), realloc() и т.д. Но иногда может понадобиться память, которая выровнена тем или иным способом. Другими словами, адрес первого выделенного байта является кратным какого-нибудь числа. (Например, на некоторых системах копирование памяти осуществляется значительно быстрее, если используются буфера, выровненные по границе слова.) Такую службу предоставляют две функции:

#include <stdlib.h>


int posix_memalign(void **memptr, size_t alignment, size_t size);

 /* POSIX ADV */

void *memalign(size_t boundary, size_t size); /* Обычная */

posix_memalign() является более новой функцией; она является частью другого необязательного расширения, «Консультативной информации» («Advisory Information»). Работа функции отличается от других функций выделения памяти Linux. При наличии проблемы она не возвращает -1. Вместо этого возвращаемое значение равно 0 при успехе или значению errno в случае неудачи. Аргументы следующие:

void **memptr

Указатель на переменную void*. Указываемая переменная будет содержать адрес выделенного блока памяти. Выделенная память освобождается с помощью free().

size_t alignment

Требуемое выравнивание. Оно должно быть кратно sizeof(void*) и быть степенью двойки.

size_t size

Число выделяемых байтов.

memalign() является нестандартной, но широко доступной функцией, которая работает сходным образом. Возвращаемое значение равно NULL в случае неудачи и запрошенному блоку памяти при успехе, причем boundary (степень двойки) обозначает выравнивание, a size — затребованный размер памяти.

Традиционно выделенная memalign() память не могла быть освобождена с помощью free(), поскольку memalign() использовала для выделения памяти malloc() и возвращала указатель на выровненный подходящим образом байт где-то внутри блока. Версия GLIBC не имеет этой проблемы. Из этих двух функций следует использовать posix_memalign(), если она у вас есть.

14.2. Блокировка файлов

Современные системы Unix, включая GNU/Linux, дают вам возможность заблокировать часть файла или весь файл для чтения или записи. Подобно многим частям Unix API, которые были разработаны после V7, имеется несколько несовместимых способов осуществить блокировку файлов. Данный раздел рассматривает эти возможности.

14.2.1. Концепции блокировки файлов

Также, как замок на вашей двери предотвращает нежелательные проникновения в ваш дом, блокировка файла предотвращает доступ к данным в файле. Блокировка файлов была добавлена в Unix после разработки V7 (от которой происходят все современные системы Unix), и соответственно в течение некоторого времени в различных системах Unix были доступны и использовались несколько несовместимых механизмов блокировки файлов. Как в BSD Unix, так и в System V были собственные несочетающиеся вызовы для блокировки. В конечном счете POSIX формализовал способ осуществления блокировки файлов System V. К счастью, названия функций в System V и BSD были различны, так что GNU/Linux, в попытке угодить всем, поддерживает обе разновидности блокировок.

Табл. 14.1 суммирует различные виды блокировок.


Таблица 14.1. Функции блокировки файлов

Источник Функция Диапазон Весь файл Чтение/запись Вспомогательный Обязательный
BSD flock()
POSIX fcntl()
POSIX lockf()
Имеются следующие аспекты блокировки файлов:

Блокировка записей

Блокировка записи является блокировкой части файла. Поскольку файлы Unix являются просто потоками байтов, было бы корректнее использовать термин блокировка диапазона (range lock), поскольку осуществляется блокировка диапазона байтов. Тем не менее, термин «блокировка записей» общеупотребительный.

Блокировка всего файла

Блокировка всего файла, как предполагает название, блокирует весь файл, даже если его размер меняется в блокированном состоянии. Интерфейс BSD предусматривает блокирование лишь всего файла. Для блокирования всего файла с использованием интерфейса POSIX указывают нулевую длину. Это интерпретируется особым образом как «весь файл».

Блокировка чтения

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

Блокировка записи

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

Вспомогательная блокировка

Вспомогательная блокировка (advisory lock) тесно соответствует замку на двери. Говорят, «замки существуют для честных людей», что означает, что если кто-нибудь на самом деле захочет вломиться в ваш дом, он, возможно, найдет способ это сделать, несмотря на наличие замка в двери. То же и со вспомогательной блокировкой; она работает лишь тогда, когда тот, кто пытается получить доступ к заблокированному файлу, сначала пытается получить блокировку. Однако, программа может совершенно игнорировать вспомогательные блокировки и делать с файлом, что захочет (конечно, пока это разрешается правами допуска файла).

Обязательная блокировка

Обязательная блокировка является более строгой: когда установлена обязательная блокировка, ни один другой процесс не может получить доступ к заблокированному файлу. Любой процесс, который пытается игнорировать это, либо сам блокируется до снятия блокировки файла, либо его попытка завершится неудачей. (Под GNU/Linux по крайней мере это включает root!)

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

POSIX стандартизует лишь вспомогательную блокировку. Обязательная блокировка доступна на GNU/Linux, а также в ряде коммерческих систем Unix, но детали варьируют. Далее в данном разделе мы рассмотрим детали для GNU/Linux.

14.2.2. Блокировка POSIX: fcntl() и lockf()

Системный вызов fcntl() (file control — управление файлом) используется для блокировки файла. (Другое использование fcntl() было описано в разделе 9.4.3 «Управление атрибутами файла: fcntl()».) Он объявлен следующим образом:

#include <unistd.h> /* POSIX */

#include <fcntl.h>


int fcntl(int fd, int cmd); /* Not relevant for file locking */

int fcntl(int fd, int cmd, long arg); /* Not relevant for file locking */

int fcntl(int fd, int cmd, struct flock *lock);

Аргументы следующие:

fd Дескриптор файла для открытого файла.

cmd Одна или более именованных констант, определенных в <fcntl.h>. Ниже они описаны более подробно.

lock Указатель на struct flock, описывающую нужный блок.

14.2.2.1. Описание блокировки

Прежде чем рассмотреть осуществление блокировки, давайте исследуем описание блокировки в операционной системе. Это делается при помощи структуры struct flock, которая описывает диапазон блокируемых байтов и вид нужной блокировки. Стандарт POSIX утверждает, что struct lock содержит «по крайней мере» определенные члены. Это позволяет разработчикам предоставлять при желании дополнительные члены структуры. Из слегка отредактированной справочной страницы fcntl(3):

struct flock {

 ...

 short l_type; /* Тип блокировки: F_RDLCK, F_WRLCK, F_UNLCK */

 short l_whence; /* Как интерпретируется l_start:

                    SEEK_SET, SEEK_CUR, SEEK_END */

 off_t l_start; /* Начальное блокируемое смещение */

 off_t l_len; /* Число блокируемых байтов;

                 0 означает от начала до конца файла */

 pid_t l_pid; /* PID блокирующего процесса (только F_GETLK) */

 ...

};

Поле l_start является смешением начального байта блокируемого участка. l_len является длиной блокируемого участка, т. е. общим числом блокируемых байтов. l_whence указывает место в файле, относительно которого отсчитывается l_start, значения те же, что и для аргумента whence функции lseek() (см раздел 4.5 «Произвольный доступ: перемещения внутри файла»), отсюда и название поля. Эта структура самодостаточна: смещение l_start и значение l_whence не связаны с текущим файловым указателем для чтения или записи. Пример кода мог бы выглядеть таким образом:

struct employee { /* что угодно */ }; /* Описание сотрудника */

struct flock lock; /* Структура блока */

...

/* Заблокировать структуру для шестого сотрудника */

lock.l_whence = SEEK_SET; /* Абсолютное положение */

lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */

lock.l_len = sizeof(struct employee); /* Блокировать одну запись */

Используя SEEK_CUR или SEEK_END, вы можете заблокировать участки, начиная от текущего смещения в файле или относительно конца файла соответственно. Для этих двух случаев l_start может быть отрицательным, пока абсолютное начало не меньше нуля. Таким образом, чтобы заблокировать последнюю запись в файле:

/* Заблокировать запись последнего сотрудника */

lock.l_whence = SEEK_END; /* Относительно EOF */

lock.l_start = -1 * sizeof (struct employee);

 /* Начало последней структуры */

lock.l_len = sizeof(struct employee); /* Заблокировать одну запись */

Установка l_len в 0 является особым случаем. Он означает блокировку файла от начального положения, указанного с помощью l_start и l_whence, и до конца файла. Сюда входят также любые области за концом файла. (Другими словами, если заблокированный файл увеличивается в размере, область блокировки расширяется таким образом, чтобы продолжать охватывать весь файл.) Таким образом, блокирование всего файла является вырожденным случаем блокирования одной записи:

lock.l_whence = SEEK_SET; /* Абсолютное положение */

lock.l_start = 0; /* Начало файла */

lock.l_len = 0; /* До конца файла */

Справочная страница fnctl(3) имеет примечание:

POSIX 1003.1-2001 допускает отрицательные значения l_len. (И если это так, описываемый блоком интервал охватывает байты с l_start + l_len вплоть до l_start - 1 включительно.) Однако, в этой ситуации системный вызов Linux для современных ядер возвращает EINVAL.

(Мы заметили, что справочная страница относится к версиям ядер 2.4.x; стоит проверить текущую справочную страницу, если ваша система новее.)

Теперь, когда мы знаем, как описать где блокируется файл, мы можем описать тип блокировки с помощью l_type. Возможные значения следующие:

F_RDLCK  Блокировка чтения. Для применения блокировки чтения файл должен быть открыт для чтения.

F_WRLCK  Блокировка записи. Для применения блокировки записи файл должен быть открыт для записи.

F_UNLCK  Освобождение предыдущей блокировки.

Таким образом, полная спецификация блокировки включает установку в структуре struct flock значений четырех полей: трех для указания блокируемой области и четвертого для описания нужного типа блока.

Значение F_UNLCK для l_type снимает блокировку. В общем, это простейший способ снять те самые блоки, которые были установлены ранее, но можно «расщепить» блок, освободив диапазон байтов в середине ранее установленного более крупного блока. Например:

struct employee { /* что угодно */ }; /* Описание сотрудника */

struct flock lock; /* Структура блока */

...

/* Заблокировать сотрудников 6-8 */

lock.l_whence = SEEK_SET; /* Абсолютное положение */

lock.l_start = 5 * sizeof(struct employee); /* Начало 6-й структуры */

lock.l_len = sizeof(struct employee) * 3; /* Заблокировать 3 записи */

/* ...установка блокировки (см. следующий раздел)... */

/* Освобождение записи 7: предыдущий блок расщепляется на два: */

lock.l_whence = SEEK_SET; /* Абсолютное положение */

lock.l_start = 6 * sizeof(struct employee); /* Начало 7-й структуры */

lock.l_len = sizeof(struct employee) * 1; /* Разблокирование 1-й записи */

/* ...снятие блокировки (см. следующий раздел)... */

14.2.2.2. Установка и снятие блокировок

После заполнения структуры struct flock следующим шагом является запрос блокировки. Этот шаг осуществляется с помощью соответствующего значения аргумента cmd функции fcntl():

F_GETLK   Узнать, можно ли установить блокировку.

F_SETLK   Установить или снять блокировку.

F_SETLKW  Установить блокировку, подождав, пока это будет возможным.

Команда F_GETLK является командой «Мама, можно мне?» Она осведомляется, доступна ли описанная struct flock блокировка. Если она доступна, блокировка не устанавливается; вместо этого операционная система изменяет поле l_type на F_UNLCK. Другие поля остаются без изменений.

Если блокировка недоступна, операционная система заполняет различные поля сведениями, описывающими уже установленные блокировки, которые препятствуют установке новой. В этом случае l_pid содержит PID процесса, владеющего соответствующей блокировкой.[152] Если блокировка уже установлена, нет другого выбора, кроме ожидания в течение некоторого времени и новой попытки установки блокировки или вывода сообщения об ошибке и отказа от дальнейших попыток.

Команда F_SETLK пытается установить указанную блокировку. Если fcntl() возвращает 0, блокировка была успешно установлена. Если она возвращает -1, блокировку установил другой процесс. В этом случае в errno устанавливается либо EAGAIN (попытайтесь снова позже) или EACCESS (нет доступа). Возможны два значения, чтобы удовлетворить старым системам.

Команда F_SETLKW также пытается установить указанную блокировку. Она отличается от F_SETLK тем, что будет ждать, пока установка блокировки не окажется возможной.

Выбрав соответствующее значение для аргумента cmd, передайте его в качестве второго аргумента fcntl() вместе с указателем на заполненную структуру struct flock в качестве третьего аргумента:

struct flock lock;

 int fd;

 /* ...открыть файл, заполнить struct flock... */

 if (fcntl(fd, F_SETLK, &lock) < 0) {

 /* Установить не удалось, попытаться восстановиться */

}

Функция lockf()[153] предоставляет альтернативный способ установки блокировки в текущем положении файла.

#include <sys/file.h> /* XSI */


int lockf(int fd, int cmd, off_t len);

Дескриптор файла fd должен быть открыт для записи. len указывает число блокируемых байтов: от текущего положения (назовем его pos) до pos + len байтов, если len положительно, или от pos - len до pos - 1, если len отрицательно. Команды следующие:

F_LOCK   Устанавливает исключительную блокировку диапазона. Вызов блокируется до тех пор, пока блокировка диапазона не станет возможной.

F_TLOCK  Пытается установить блокировку. Это похоже на F_LOCK, но если блокировка недоступна, F_TLOCK возвращает ошибку.

F_ULOCK  Разблокирует указанный раздел. Это может вызвать расщепление блокировки, как описано выше.

F_TEST   Проверяет, доступна ли блокировка. Если доступна, возвращает 0 и устанавливает блокировку. В противном случае возвращает -1 и устанавливает в errno EACCESS.

Возвращаемое значение равно 0 в случае успеха и -1 при ошибке, с соответствующим значением в errno. Возможные значения ошибок включают:

EAGAIN Файл заблокирован, для F_TLOCK или F_TEST.

EDEADLK Для F_TLOCK эта операция создала бы тупик.[154]

ENOLCK Операционная система не смогла выделить блок.

Полезна комбинация F_TLOCK и EDEADLK: если вы знаете, что тупик не может возникнуть никогда, используйте F_LOCK. В противном случае, стоит обезопасить себя и использовать F_TLOCK. Если блокировка доступна, она осуществляется, но если нет, у вас появляется возможность восстановления вместо блокирования в ожидании, возможно, навечно.

Завершив работу с заблокированным участком, его следует освободить. Для fcntl() возьмите первоначальную struct lock, использованную для блокирования, и измените поле l_type на F_UNLCK. Затем используйте F_SETLK в качестве аргумента cmd:

lock.l_whence = ... ; /* Как раньше */

lock.l_start = ... ; /* Как раньше */

lock.l_len = ... ; /* Как раньше */

lock.l_type = F_UNLCK; /* Разблокировать */

if (fcntl(fd, F_SETLK, &lock) < 0) {

 /* обработать ошибку */

}

/* Блокировка была снята */

Код, использующий lockf(), несколько проще. Для краткости мы опустили проверку ошибок:

off_t curpos, len;

curpos = lseek(fd, (off_t)0, SEEK_CUR); /* Получить текущее положение */

len = ... ; / * Установить соответствующее число блокируемых байтов */

lockf(fd, F_LOCK, len); / * Осуществить блокировку */

/* ...здесь использование заблокированного участка... */

lseek(fd, curpos, SEEK_SET); / * Вернуться к началу блокировки */

lockf(fd, F_ULOCK, len); /* Разблокировать файл */

Если вы не освободите блокировку явным образом, операционная система сделает это за вас в двух случаях. Первый случай, когда процесс завершается (либо при возвращении из main(), либо с использованием функции exit(), которую мы рассматривали в разделе 9.1.5.1 «Определение статуса завершения процесса»). Другим случаем является вызов close() с дескриптором файла: больше об этом в следующем разделе.

14.2.2.3. Предостережения по поводу блокировок

Имеется несколько предостережений, о которых нужно знать при блокировках файлов:

• Как описано ранее, вспомогательная блокировка является именно этим. Не взаимодействующий процесс может делать все, что хочет, за спиной (так сказать) процесса, осуществляющего блокировку.

• Эти вызовы не следует использовать в сочетании с библиотекой <stdio.h>. Эта библиотека осуществляет свое собственное буферирование. Хотя вы можете получить с помощью fileno() дескриптор нижележащего файла, действительное положение в файле может быть не там, где вы думаете. В общем, стандартная библиотека ввода/вывода не понимает блокировок файлов.

• Держите в уме, что блокировки после fork не наследуются порожденными процессами, но они остаются на своем месте после exec.

• Вызов close() с любым открытым для файла дескриптором удаляет все блокировки файла процессом, даже если другие дескрипторы для файла остаются открытыми.

То, что close() работает таким образом, является неудачным, но поскольку так была реализована первоначальная блокировка в fcntl(), POSIX ее стандартизует. Стандартизация такого поведения позволяет избежать порчи существующего кода для Unix.

14.2.3. Блокирование BSD: flock()

4.2 BSD представило свой собственный механизм блокировки, flock()[155]. Функция объявлена следующим образом:

#include <sys/file.h> /* Обычный */


int flock(int fd, int operation);

Дескриптор fd представляет открытый файл. Имеются следующие операции:

LOCK_SH  Создает совместную блокировку. Может быть несколько совместных блокировок.

LOCK_EX  Создает исключительную блокировку. Может быть лишь одна такая блокировка.

LOCK_UN  Удаляет предыдущую блокировку.

LOCK_NB  При использовании побитового ИЛИ с LOCK_SH или LOCK_EX позволяет избежать блокирования функции, если блокировка файла невозможна.

По умолчанию запросы блокировки файла будут блокировать функцию (не давать ей вернуться), если существует конкурирующая блокировка. Запрашивающая функция возвращается, когда конкурирующая блокировка файла снимается и осуществляется запрошенная функцией блокировка файла. (Это предполагает, что по умолчанию имеется возможность возникновения тупика.) Чтобы попытаться заблокировать файл без блокирования функции, добавьте посредством побитового ИЛИ значение LOCK_NB к имеющемуся значению operation.

Отличительными моментами flock() являются следующие:

• Блокировка с помощью flock() является вспомогательной; программа, не использующая блокировку, может прийти и испортить без всяких сообщений об ошибках файл, заблокированный с помощью flock().

• Блокируется весь файл. Нет механизма для блокировки только части файла.

• То, как был открыт файл, не влияет на тип блокировки, который может быть использован. (Сравните это с fcntl(), при использовании которой файл должен быть открыт для чтения для получения блокировки чтения, или для записи для блокировки записи.)

• Несколько открытых для одного и того же файла дескрипторов используют совместную блокировку. Для удаления блокировки может использоваться любой из них. В отличие от fcntl(), когда нет явного разблокирования, блокировка не удаляется до тех пор, пока не будут закрыты все открытые дескрипторы файла.

• Процесс может иметь лишь одну блокировку файла с помощью flock(); последовательный вызов flock() с двумя различными типами блокировок изменяет тип блокировки на новый.

• На системах GNU/Linux блокировки flock() совершенно независимы от блокировок fcntl(). Многие коммерческие системы Unix реализуют flock() в виде «оболочки» поверх fcntl(), но их семантика различается.

Мы не рекомендуем использовать flock() в новых программах, поскольку ее семантика не такая гибкая и поскольку она не стандартизована POSIX. Поддержка ее в GNU/Linux осуществляется главным образом для обратной совместимости с программным обеспечением, написанным для старых систем BSD Unix.

ЗАМЕЧАНИЕ. Справочная страница GNU/Linux flock(2) предупреждает, что блокировки flock() не работают для смонтированных удаленных файлов. Блокировки fcntl() работают, при условии, что у вас достаточно новая версия Linux и сервер NFS поддерживает блокировки файлов

14.2.4. Обязательная блокировка

Большинство коммерческих систем Unix поддерживают в дополнение к вспомогательной обязательную блокировку файлов. Обязательная блокировка работает лишь с fcntl(). Обязательная блокировка файла контролируется установками прав доступа файла, в частности, путем добавления к файлу бита setgid с помощью команды chmod.

$ echo hello, world > myfile /* Создать файл */

$ ls -l myfile /* Отобразить права доступа */

-rw-r--r-- 1 arnold devel 13 Apr 3 17:11 myfile

$ chmod g+s myfile /* Добавить бит setgid */

$ ls -l myfile /* Показать новые права доступа */

-rw-r-Sr-- 1 arnold devel 13 Apr 3 17:11 myfile

Бит права на исполнение группой должен быть оставлен сброшенным. S показывает, что бит setgid установлен, но что бит права на исполнение — нет; если бы были установлены оба бита, была бы использована строчная буква s.

Комбинация установленного бита setgid и сброшенного бита права на исполнение группой обычно бессмысленно. По этой причине, она была выбрана разработчиками System V для обозначения «использования обязательного блокирования». И в самом деле, добавления этого бита достаточно, чтобы заставить коммерческую систему Unix, такую как Solaris, использовать блокировку файлов.

На системах GNU/Linux несколько другая история. Для обязательных блокировок файл должен иметь установленный бит setgid, но этого одного недостаточно. Файловая система, содержащая файл, также должна быть смонтирована с опцией mand в команде mount.

Мы уже рассмотрели файловые системы, разделы диска, монтирование и команду mount, главным образом, в разделе 8.1 «Монтирование и демонтирование файловых систем». Мы можем продемонстрировать обязательную блокировку с помощью небольшой программы и файловой системой для тестирования на гибком диске. Для начала, вот программа:

1  /* ch14-lockall.c --- Демонстрация обязательной блокировки. */

2

3  #include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

4  #include <errno.h> /* объявление errno */

5  #include <fcntl.h> /* для флагов open() */

6  #include <string.h> /* объявление strerror() */

7  #include <unistd.h> /* для ssize_t */

8  #include <sys/types.h>

9  #include <sys/stat.h> /* для mode_t */

10

11 int

12 main(int argc, char **argv)

13 {

14  int fd;

15  int i, j;

16  mode_t rw_mode;

17  static char message[] = "hello, world\n";

18  struct flock lock;

19

20  if (argc != 2) {

21   fprintf(stderr, "usage: %s file\n", argv[0]);

22   exit(1);

23  }

24

25  rw_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; / * 0644 */

26  fd = open(argv[1], O_RDWR|O_TRUNC|O_CREAT|O_EXCL, rw_mode);

27  if (fd < 0) {

28   fprintf(stderr, "%s: %s: cannot open for read/write: %s\n",

29    argv[0], argv[1], strerror(errno));

30   (void)close(fd);

31   return 1;

32  }

33

34  if (write(fd, message, strlen(message)) != strlen(message)) {

35   fprintf(stderr, "%s: %s: cannot write: %s\n",

36    argv[0], argv[1], strerror(errno));

37   (void)close(fd);

38   return 1;

39  }

40

41  rw_mode |= S_ISGID; /* добавить бит обязательной блокировки */

42

43  if (fchmod(fd, rw_mode) < 0) {

44   fprintf(stderr, "%s: %s: cannot change mode to %o: %s\n",

45    argv[0], argv[1], rw_mode, strerror(errno));

46   (void)close(fd);

47   return 1;

48  }

49

50  /* заблокировать файл */

51  memset(&lock, '\0', sizeof(lock));

52  lock.l_whence = SEEK_SET;

53  lock.l_start = 0;

54  lock.l_len =0; /* блокировка всего файла */

55  lock.l_type = F_WRLCK; /* блокировка записи */

56

57  if (fcntl(fd, F_SETLK, &lock) < 0) {

58   fprintf(stderr, "%s: %s: cannot lock the file: %s\n",

59    argv[0], argv[1], strerror(errno));

60   (void)close(fd);

61   return 1;

62  }

63

64  pause();

65

66  (void)close(fd);

67

68  return 0;

69 }

Программа устанавливает права доступа и создает файл, указанный в командной строке (строки 25 и 26). Затем она записывает в файл некоторые данные (строка 34). Строка 41 добавляет к правам доступа бит setgid, а строка 43 изменяет их. (Системный вызов fchmod() обсуждался в разделе 5.5.2 «Изменение прав доступа: chmod() и fchmod()».)

Строки 51–55 устанавливают struct flock для блокировки всего файла, а затем блокировка осуществляется реально в строке 57. Выполнив блокировку, программа засыпает, используя системный вызов pause() (см. раздел 10.7 «Сигналы для межпроцессного взаимодействия»). После этого программа закрывает дескриптор файла и завершается. Вот расшифровка с комментариями, демонстрирующая использование обязательной блокировки файлов:

$ fdformat /dev/fd0 /* Форматировать гибкий диск */

Double -sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.

Formatting ... done

Verifying ... done

$ /sbin/mke2fs /dev/fd0 /* Создать файловую систему Linux */

/* ...множество вывода опущено... */

$ su /* Стать root, чтобы использовать mount */

Password: /* Пароль не отображается */

# mount -t ext2 -о mand /dev/fd0 /mnt/floppy /* Смонтировать гибкий

диск, с возможностью блокировок */

# suspend /* Приостановить оболочку root */

[1]+ Stopped su

$ ch14-lockall /mnt/floppy/x & /* Фоновая программа */

[2] 23311 /* содержит блокировку */

$ ls -l /mnt/floppy/x /* Посмотреть файл */

-rw-r-Sr-- 1 arnold devel 13 Apr 6 14:23 /mnt/floppy/x

$ echo something > /mnt/floppy/x /* Попытаться изменить файл */

bash2: /mnt/floppy/x: Resource temporarily unavailable

 /* Возвращается ошибка */

$ kill %2 /* Завершить программу с блокировкой */

$ /* Нажать ENTER */

[2]- Terminated ch14-lockall /mnt/floppy/x /* Программа завершена */

$ echo something > /mnt/floppy/x /* Новая попытка изменения работает */

$ fg /* Вернуться в оболочку root */

su

# umount /mnt/floppy /* Демонтировать гибкий диск */

# exit /* Работа с оболочкой root закончена */

$

Пока выполняется ch14-lockall, она владеет блокировкой. Поскольку это обязательная блокировка, перенаправления ввода/вывода оболочки завершаются неудачей. После завершения ch14-lockall блокировки освобождаются, и перенаправление ввода/вывода достигает цели. Как упоминалось ранее, под GNU/Linux даже root не может аннулировать обязательную блокировку файла.

Немного отклоняясь в сторону, гибкие диски представляют отличный испытательный стенд для изучения того, как использовать инструменты, работающие с файловыми системами. Если вы сделаете что-то, что разрушит данные на гибком диске, это вряд ли будет катастрофическим, тогда как экспериментирование с действующими разделами на обычных жестких дисках значительно более рискованно.

14.3. Более точное время

Системный вызов time() и тип time_t представляют время в секундах в формате отсчета с начала Эпохи. Разрешения в одну секунду на самом деле недостаточно, сегодняшние машины быстры, и часто бывает полезно различать временные интервалы в долях секунды. Начиная с 4.2 BSD, Berkley Unix представил ряд системных вызовов, которые сделали возможным получение и использование времени в долях секунд. Эти вызовы доступны на всех современных системах Unix, включая GNU/Linux.

14.3.1. Время в микросекундах: gettimeofday()

Первой задачей являетсяполучение времени дня:

#include <sys/time.h>


int gettimeofday(struct timeval *tv, void *tz); /* определение POSIX, а не GLIBC */

gettimeofday() позволяет получить время дня.[156] В случае успеха возвращается 0, при ошибке -1. Аргументы следующие:

struct timeval *tv

Этот аргумент является указателем на struct timeval, которая вскоре будет описана и в которую система помещает текущее время.

void *tz

Это аргумент больше не используется; он имеет тип void*, поэтому он всегда должен равняться NULL. (Справочная страница описывает, для чего он использовался, а затем утверждает, что он устарел. Прочтите, если интересуетесь подробностями.)

Время представлено структурой struct timeval:

struct timeval {

 long tv_sec; /* секунды */

 long tv_usec; /* микросекунды */

};

Значение tv_sec представляет секунды с начала Эпохи; tv_usec является числом микросекунд в секунде.

Справочная страница GNU/Linux gettimeofday(2) документирует также следующие макросы:

#define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec)

#define timercmp(tvp, uvp, cmp) \

 ((tvp)->tv_sec cmp (uvp)->tv_sec || \

 (tvp)->tv_sec == (uvp)->tv_sec && \

 (tvp)->tv_usec cmp (uvp)->tv_usec)

#define timerclear(tvp) ((tvp)->tv_sec = (tvp)->tv_usec = 0)

Эти макросы работают со значениями struct timeval*; то есть указателями на структуры, и их использование должно быть очевидным из их названий и кода. Особенно интересен макрос timercmp(): третьим аргументом является оператор сравнения для указания вида сравнения. Например, рассмотрим определение того, является ли одна struct timeval меньше другой:

struct timeval t1, t2;

...

if (timercmp(&t1, & t2, <))

 /* t1 меньше, чем t2 */

Макрос развертывается в

((&t1)->tv_sec < (&t2)->tv_sec || \

(&t1)->tv_sec == (&t2)->tv_sec && \

(&t1)->tv_usec < (&t2)->tv_usec)

Это значит: «если t1.tv_sec меньше, чем t2.tv_sec, ИЛИ если они равны и t1.tv_usec меньше, чем t2.tv_usec, тогда…».

14.3.2. Файловое время в микросекундах: utimes()

В разделе 5.5.3 «Изменение временных отметок: utime()» был описан системный вызов utime() для установки времени последнего обращения и изменения данного файла. Некоторые файловые системы хранят эти временные отметки с разрешением в микросекунды (или еще точнее). Такие системы предусматривают системный вызов utimes() (обратите внимание на завершающую s в названии) для установки времени обращения к файлу и его изменения с точностью до микросекунд:

#include <sys/time.h> /* XSI */


int utimes(char *filename, struct timeval tvp[2]);

Аргумент tvp должен указывать на массив из двух структур struct timeval, значения используются для времени доступа и изменения соответственно. Если tvp равен NULL, система использует текущее время дня.

POSIX обозначает ее как «традиционную» функцию, что означает, что она стандартизуется лишь для поддержки старого кода и не должна использоваться для новых приложений. Главная причина, пожалуй, в том, что нет определенного интерфейса для получения времени доступа и изменения файла в микросекундах; struct stat содержит лишь значения time_t, а не значения struct timeval.

Однако, как упоминалось в разделе 5.4.3 «Только Linux: указание файлового времени повышенной точности», Linux 2.6 (и более поздние версии) действительно предоставляет доступ к временным отметкам с разрешением в наносекунды при помощи функции stat(). Некоторые другие системы (такие, как Solaris) также это делают.[157] Таким образом, utimes() полезнее, чем кажется на первый взгляд, и несмотря на ее «традиционный» статус, нет причин не использовать ее в своих программах.

14.3.3. Интервальные таймеры: setitimer() и getitimer()

Функция alarm() (см. раздел 10.8.1 «Сигнальные часы: sleep(), alarm() и SIGALRM») организует отправку сигнала SIGALRM после истечения данного числа секунд. Ее предельным разрешением является одна секунда. Здесь также BSD 4.2 ввело функцию и три различных таймера, которые используют время в долях секунды.

Интервальный таймер подобен многократно использующимся сигнальным часам. Вы устанавливаете начальное время, когда он должен «сработать», а также как часто это должно впоследствии повторяться. Оба этих значения используют объекты struct timeval; т.е. они (потенциально) имеют разрешение в микросекундах. Таймер «срабатывает», доставляя сигнал; таким образом, нужно установить для таймера обработчик сигнала, желательно до установки самого таймера.

Существуют три различных таймера, описанных в табл. 14.2.


Таблица 14.2. Интервальные таймеры

Таймер Сигнал Функция
ITIMER_REAL SIGALRM Работает в реальном режиме
ITIMER_VIRTUAL SIGVTALRM Работает, когда процесс выполняется в режиме пользователя
ITIMER_PROF SIGPROF Работает, когда процесс выполняется в режиме пользователя или ядра.
Использование первого таймера, ITIMER_REAL, просто. Таймер работает в реальном времени, посылая SIGALRM по истечении заданного количества времени. (Поскольку посылается SIGALRM, нельзя смешивать вызовы setitimer() с вызовами alarm(), а смешивание их с вызовом sleep() также опасно; см. раздел 10.8.1 «Сигнальные часы, sleep(), alarm() и SIGALRM».)

Второй таймер, ITIMER_VIRTUAL, также довольно прост. Он действует, когда процесс исполняется, но лишь при выполнении кода пользователя (приложения) Если процесс заблокирован во время ввода/вывода, например, на диск, или, еще важнее, на терминал, таймер приостанавливается.

Третий таймер, ITIMER_PROF, более специализированный. Он действует все время, пока выполняется процесс, даже если операционная система делает что-нибудь для процесса (вроде ввода/вывода). В соответствии со стандартом POSIX, он «предназначен для использования интерпретаторами при статистическом профилировании выполнения интерпретируемых программ». Установив как для ITIMER_VIRTUAL, так и для ITIMER_PROF идентичные интервалы и сравнивая разницу времени срабатывания двух таймеров, интерпретатор может узнать, сколько времени проводится в системных вызовах для выполняющейся интерпретируемой программы[158]. (Как сказано, это довольно специализировано.) Двумя системными вызовами являются:

#include <sys/time.h> /* XSI */


int getitimer(int which, struct itimerval *value);

int setitimer(int which, const struct itimerval *value,

 struct itimerval *ovalue);

Аргумент which является одной из перечисленных ранее именованных констант, указывающих таймер, getitimer() заполняет struct itimerval, на которую указывает value, текущими установками данного таймера, setitimer() устанавливает для данного таймера значение в value. Если имеется ovalue, функция заполняет ее текущим значением таймера. Используйте для ovalue NULL, если не хотите беспокоиться о текущем значении. Обе функции возвращают в случае успеха 0 и -1 при ошибке, struct itimerval состоит из двух членов struct timeval:

struct itimerval {

 struct timeval it_interval; /* следующее значение */

 struct timeval it_value;    /* текущее значение */

};

Прикладным программам не следует ожидать, что таймеры будут с точностью до микросекунд. Справочная страница getitimer(2) дает следующее объяснение:

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

Из этих трех таймеров ITIMER_REAL кажется наиболее полезным. Следующая программа, ch14-timers.c, показывает, как читать данные с терминала, но с тайм-аутом, чтобы программа не зависала на бесконечное время, ожидая ввода:

1  /* ch14-timers.c --- демонстрация интервальных таймеров */

2

3  #include <stdio.h>

4  #include <assert.h>

5  #include <signal.h>

6  #include <sys/time.h>

7

8  /* handler --- обрабатывает SIGALRM */

9

10 void handler(int signo)

11 {

12  static const char msg[] = "\n*** Timer expired, you lose ***\n";

13

14  assert(signo == SIGALRM);

15

16  write(2, msg, sizeof(msg) - 1);

17  exit(1);

18 }

19

20 /* main --- установить таймер, прочесть данные с тайм-аутом */

21

22 int main(void)

23 {

24  struct itimerval tval;

25  char string[BUFSIZ];

26

27  timerclear(&tval.it_interval); /* нулевой интервал означает не сбрасывать таймер */

28  timerclear(&tval.it_value);

29

30  tval.it_value.tv_sec = 10; /* тайм-аут 10 секунд */

31

32  (void)signal(SIGALRM, handler);

33

34

35  printf("You have ten seconds to enter\nyour name, rank, and serial number: ");

36  (void)setitimer(ITIMER_REAL, &tval, NULL);

37  if (fgets(string, sizeof string, stdin) != NULL) {

38   (void)setitimer(ITIMER_REAL, NULL, NULL); /* выключить таймер */

39   /* обработать оставшиеся данные, вывод диагностики для иллюстрации */

40   printf("I'm glad you are being cooperative.\n");

41  } else

42   printf("\nEOF, eh? We won't give up so easily'\n");

43

44  exit(0);

45 }

Строки 10–18 представляют обработчик сигнала для SIGALRM; вызов assert() гарантирует, что обработчик сигнала был установлен соответствующим образом. Тело обработчика выводит сообщение и выходит, но оно может делать что-нибудь более подходящее для крупномасштабной программы.

В функции main() строки 27–28 очищают два члена struct timeval структуры struct itimerval.tval. Затем строка 30 устанавливает тайм-аут в 10 секунд. Установка tval.it_interval в 0 означает, что нет повторяющегося сигнала; он срабатывает лишь однажды. Строка 32 устанавливает обработчик сигнала, а строка 34 выводит приглашение.

Строка 36 устанавливает таймер, а строки 37–42 выводят соответствующие сообщения, основываясь на действиях пользователя. Реальная программа выполняла бы в этот момент свою задачу. Важно здесь обратить внимание на строку 38, которая отменяет таймер, поскольку были введены действительные данные.

ЗАМЕЧАНИЕ. Между строками 37 и 38 имеется намеренное состояние гонки. Все дело в том, что если пользователь не вводит строку в течение отведенного таймером времени, будет доставлен сигнал, и обработчик сигнала выведет сообщение «you lose».

Вот три успешных запуска программы:

$ ch14-timers /* Первый запуск, ничего не вводится */

You have ten seconds to enter

your name, rank, and serial number:

*** Timer expired, you lose ***


$ ch14-timers /* Второй запуск, ввод данных */

You have ten seconds to enter

your name, rank, and serial number: Jamas Kirk, Starfleet Captain, 1234

I'm glad you are being cooperative.


$ ch14-timers /* Третий запуск, ввод EOF (^D) */

You have ten seconds to enter

your name, rank, and serial number: ^D

EOF, eh? We won't give up so easily!

POSIX оставляет неопределенным, как интервальные таймеры взаимодействуют с функцией sleep(), если вообще взаимодействуют. GLIBC не использует для реализации sleep() функцию alarm(), поэтому на системах GNU/Linux sleep() не взаимодействует с интервальным таймером. Однако, для переносимых программ, вы не можете делать такое предположение.

14.3.4. Более точные паузы: nanosleep()

Функция sleep() (см. раздел 10.8.1 «Сигнальные часы: sleep(), alarm() и SIGALRM») дает программе возможность приостановиться на указанное число секунд. Но, как мы видели, она принимает лишь целое число секунд, что делает невозможным задержки на короткие периоды, она потенциально может также взаимодействовать с обработчиками SIGALRM. Функция nanosleep() компенсирует эти недостатки:

#include <time.h> /* POSIX ТМР */


int nanosleep(const struct timespec *req, struct timespec *rem);

Эта функция является частью необязательного расширения POSIX «Таймеры» (TMR). Два аргумента являются запрошенным временем задержки и оставшимся числом времени в случае раннего возвращения (если rem не равен NULL). Оба являются значениями struct timespec:

struct timespec {

 time_t tv_sec; /* секунды */

 long tv_nsec;  /* наносекунды */

};

Значение tv_nsec должно быть в диапазоне от 0 до 999 999 999. Как и в случае со sleep(), время задержки может быть больше запрошенного в зависимости оттого, когда и как ядро распределяет время для исполнения процессов.

В отличие от sleep(), nanosleep() не взаимодействует ни с какими сигналами, делая ее более безопасной и более простой для использования.

Возвращаемое значение равно 0, если выполнение процесса было задержано в течение всего указанного времени. В противном случае оно равно -1, с errno, указывающим ошибку. В частности, если errno равен EINTR, nanosleep() была прервана сигналом. В этом случае, если rem не равен NULL, struct timespec, на которую она указывает, содержит оставшееся время задержки. Это облегчает повторный вызов nanosleep() для продолжения задержки.

Хотя это выглядит немного странным, вполне допустимо использовать одну и ту же структуру для обоих параметров:

struct timespec sleeptime = /* что угодно */;

int ret;

ret = nanosleep(&sleeptime, &sleeptime);

struct timeval и struct timespec сходны друг с другом, отличаясь лишь компонентом долей секунд. Заголовочный файл GLIBC <sys/time.h> определяет для их взаимного преобразования друг в друга два полезных макроса:

#include <sys/time.h> /* GLIBC */


void TIMEVAL_TO_TIMESPEC(struct timeval *tv, struct timespec *ts);

void TIMEPSEC_TO_TIMEVAL(struct timespec *ts, struct timeval *tv);

Вот они:

# define TIMEVAL_TO_TIMESPEC(tv, ts) { \

 (ts)->tv_sec = (tv)->tv_sec; \

 (ts)->tv_nsec = (tv)->tv_usec * 1000; \

}

# define TIMESPEC_TO_TIMEVAL(tv, ts) { \

 (tv)->tv_sec = (ts)->tv_sec; \

 (tv)->tv_usec = (ts)->tv_nsec / 1000; \

}

#endif

ЗАМЕЧАНИЕ. To, что некоторые системные вызовы используют микросекунды, а другие — наносекунды, в самом деле сбивает с толку. Причина этого историческая: микросекундные вызовы были разработаны на системах, аппаратные часы которых не имели более высокого разрешения, тогда как наносекундные вызовы были разработаны более недавно для систем со значительно более точными часами. C'est la vie. Почти все, что вы можете сделать, это держать под руками ваше руководство.

14.4. Расширенный поиск с помощью двоичных деревьев

В разделе 6.2 «Функции сортировки и поиска» мы представили функции для поиска и сортировки массивов. В данном разделе мы рассмотрим более продвинутые возможности.

14.4.1. Введение в двоичные деревья

Массивы являются почти простейшим видом структурированных данных. Их просто понимать и использовать. Хотя у них есть недостаток, заключающийся в том, что их размер фиксируется во время компиляции. Таким образом, если у вас больше данных, чем помещается в массив, вам не повезло. Если у вас значительно меньше данных, чем размер массива, память расходуется зря. (Хотя на современных системах много памяти, подумайте об ограничениях программистов, пишущих программы для внедренных систем, таких, как микроволновые печи и мобильные телефоны. С другого конца спектра, подумайте о проблемах программистов, имеющих дело с огромными объемами ввода, таких, как прогнозирование погоды.

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

Одной из таких структур является дерево двоичного поиска, которое мы для краткости будем называть просто «двоичным деревом» («binary tree»). Двоичное дерево хранит элементы в сортированном порядке, вводя их в дерево в нужном месте при их появлении. Поиск по двоичному дереву также осуществляется быстро, время поиска примерно такое же, как при двоичном поиске в массиве. В отличие от массивов, двоичные деревья не нужно каждый раз повторно сортировать с самого начала при добавлении к ним элементов.

У двоичных деревьев есть один недостаток. В случае, когда вводимые данные уже отсортированы, время поиска в двоичном дереве сводится ко времени линейного поиска. Техническая сторона этого вопроса должна иметь дело с тем, как двоичные деревья управляются внутренне, что вскоре будет описано.

Теперь не избежать некоторой формальной терминологии, относящейся к структурам данных. На рис. 14.1 показано двоичное дерево. В информатике деревья изображаются, начиная сверху и расширяясь вниз. Чем ниже спускаетесь вы по дереву, тем больше его глубина. Каждый объект внутри дерева обозначается как вершина (node). На вершине дерева находится корень дерева с глубиной 0. Внизу находятся концевые вершины различной глубины. Концевые вершины отличают по тому, что у них нет ответвляющихся поддеревьев (subtrees), тогда как у внутренних вершин есть по крайней мере одно поддерево. Вершины с поддеревьями иногда называют родительскими (parent), они содержат порожденные вершины (children).

Рис. 14.1. Двоичное дерево

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

Деревья двоичного поиска отличаются еще и тем, что значения, хранящиеся в левой порожденной вершине, всегда меньше значения в родительской вершине, а значения, хранящиеся в правой порожденной вершине, всегда больше значения в родительской вершине. Это предполагает, что внутри дерева нет повторяющихся значений. Этот факт также объясняет, почему деревья не эффективны при работе с предварительно отсортированными данными: в зависимости от порядка сортировки, каждый новый элемент данных сохраняется либо только слева, либо только справа от находящегося впереди него элемента, образуя простой линейный список.

К двоичным деревьям применяют следующие операции:

Ввод

Добавление к дереву нового элемента.

Поиск

Нахождение элемента в дереве.

Удаление

Удаление элемента из дерева.

Прохождение (traversal)

Осуществление какой-либо операции с каждым хранящимся в дереве элементом. Прохождение дерева называют также обходом дерева (tree walk). Есть разнообразные способы «посещения» хранящихся в дереве элементов. Обсуждаемые здесь функции реализуют лишь один из таких способов. Мы дополнительно расскажем об этом позже.

14.4.2. Функции управления деревьями

Только что описанные операции соответствуют следующим функциям:

#include <search.h> /* XSI */


void *tsearch(const void *key, void **rootp,

int (*compare)(const void*, const void*));

void *tfind(const void *key, const void **rootp,

int (*compare)(const void*, const void*));

void *tdelete(const void *key, void **rootp,

int (*compare)(const void*, const void*));


typedef enum { preorder, postorder, endorder, leaf } VISIT;

void twalk(const void *root,

void (*action)(const void *nodep, const VISIT which,

const int depth));


void tdestroy(void *root, void (*free_node)(void *nodep)); /* GLIBC*/

Эти функции были впервые определены для System V, а теперь формально стандартизованы POSIX. Они следуют структуре других, которые мы видели в разделе 6.2 «Функции сортировки и поиска»: использование указателей void* для указания на произвольные типы данных и предоставляемые пользователем функции сравнения для определения порядка. Как и для qsort() и bsearch(), функции сравнения должны возвращать отрицательное/нулевое/положительное значение, когда key сравнивается со значением в вершине дерева.

14.4.3. Ввод элемента в дерево: tsearch()

Эти процедуры выделяют память для вершин дерева. Для их использования с несколькими деревьями нужно предоставить им указатель на переменную void*, в которую они заносят адрес корневой вершины. При создании нового дерева инициализируйте этот указатель в NULL:

void *root = NULL; /* Корень нового дерева */

void *val; /* Указатель на возвращенные данные */

extern int my_compare(const void*, const void*); /* Функция сравнения */

extern char key[], key2[]; /* Значения для ввода в дерево */

val = tsearch(key, &root, my_compare);

 /* Ввести в дерево первый элемент */

/* ...заполнить key2 другим значением. НЕ изменять корень... */

val = tsearch(key2, &root, my_compare);

 /* Ввести в дерево последующий элемент */

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

Когда разыскиваемый key найден, как tsearch(), так и tfind() возвращают указатель на содержащую его вершину. Поведение функций различно, когда key не найден: tfind() возвращает NULL, a tsearch() вводит в дерево новое значение и возвращает указатель на него. Функции tsearch() и tfind() возвращают указатели на внутренние вершины дерева. Они могут использоваться в последующих вызовах в качестве значения root для работы с поддеревьями. Как мы вскоре увидим, значение key может быть указателем на произвольную структуру; он не ограничен символьной строкой, как можно было бы предположить из предыдущего примера.

Эти процедуры сохраняют лишь указатели на данные, использующиеся в качестве ключей. Соответственно это ваше дело управлять памятью для хранения значений данных, обычно с помощью malloc().

ЗАМЕЧАНИЕ. Поскольку функции деревьев хранят указатели, тщательно позаботьтесь о том, чтобы не использовать realloc() для значений, которые были использованы в качестве ключей! realloc() может переместить данные, вернув новый указатель, но процедуры деревьев все равно сохранят висящие (dangling) указатели на старые данные.

14.4.4. Поиск по дереву и использование возвращенного указателя: tfind() и tsearch()

Функции tfind() и tsearch() осуществляют поиск в двоичном дереве по данному ключу. Они принимают тот же самый набор аргументов: ключ для поиска key. указатель на корень дерева, rootp; и compare, указатель на функцию сравнения. Обе функции возвращают указатель на вершину, которая соответствует key.

Как именно использовать указатель, возвращенный tfind() и tsearch()? Во всяком случае, на что именно он указывает? Ответ заключается в том, что он указывает на вершину в дереве. Это внутренний тип; вы не можете увидеть, как он определен. Однако, POSIX гарантирует, что этот указатель может быть приведен к указателю на указатель на что бы то ни было, что вы используете в качестве ключа. Вот обрывочный код для демонстрации, а затем мы покажем, как это работает:

struct employee { /* Из главы 6 */

 char lastname[30];

 char firstname[30];

 long emp_id;

 time_t start_date;

};


/* emp_name_id_compare --- сравнение по имени, затем no ID */

int emp_name_id_compare(const void *e1p, const void *e2p) {

 /* ...также из главы 6, полностью представлено позже... */

}


struct employee key = { ... };

void *vp, *root;

struct employee *e;

/* ...заполнение данными... */


vp = tfind(&key, root, emp_name_id_compare);

if (vp != NULL) { /* it's there, use it */

 e = *((struct employee**)vp); /* Получить хранящиеся в дереве данные */

 /* использование данных в *е ... */

}

Как можно указатель на вершину использовать как указатель на указатель данных? Рассмотрим, как была бы реализована вершина двоичного дерева. В каждой вершине хранится по крайней мере указатель на элемент данных пользователя и указатели на потенциальные порожденные вершины справа и слева. Поэтому она должна выглядеть примерно так.

struct binary_tree {

 void *user_data; /* Указатель на данные пользователя */

 struct binary_tree *left; /* Порожденная вершина слева или NULL */

 struct binary_tree *right; /* Порожденная вершина справа или NULL */

/* ...здесь возможны другие поля... */

} node;

С и C++ гарантируют, что поля внутри структуры располагаются в порядке возрастания адресов. Таким образом, выражение '&node.left < &node.right' истинно. Более того, адрес структуры является также адресом ее первого поля (другими словами, игнорируя проблемы типов, '&node == &node.user_data').

Следовательно, концептуально 'е = *((struct employee**)vp);' означает:

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

2. '(struct employee**)vp' приводит адрес внутреннего указателя к нужному типу; он остается указателем на указатель, но в этот раз на struct employee. Помните, что приведение одного типа указателя к другому не изменяют значения (паттерна битов); оно меняет лишь способ интерпретации компилятором значения для анализа типов.

3. '*((struct employee**)vp)' разыменовывает вновь созданный struct employee**, возвращая годный к употреблению указатель struct employee*.

4. 'е = *((struct employee**)vp)' сохраняет это значение в е для непосредственного использования позже.

Идея проиллюстрирована на рис. 14.2.

Рис. 14.2. Вершины дерева и их указатели

Для упрощения использования возвращенного указателя вы могли бы рассмотреть определение макроса:

#define tree_data(ptr, type)(*(type**)(ptr))

...

struct employee *e;

void *vp;


vp = tfind(&key, root, emp_name_id_compare);

if (vp != NULL) { /* it's there, use it */

 e = tree_data(vp, struct employee);

 /* использование сведений в *e ... */

}

14.4.5. Обход дерева: twalk()

Функция twalk() объявлена в <search.h> следующим образом:

typedef enum { preorder, postorder, endorder, leaf } VISIT;

void twalk(const void *root,

 void (*action)(const void *nodep, const VISIT which,

const int depth));

Первый параметр является корнем дерева (не указателем на корень). Второй является указателем на функцию обратного вызова, которая вызывается с тремя аргументами, указателем на исследуемую вершину дерева; типом перечисления, указывающим, как осуществляется обход данной вершины; и целого, обозначающего глубину текущей вершины (корень находится на глубине 0, как объяснялось ранее).

Использование функции обратного вызова здесь такое же, как для nftw() (см. раздел 8.4.3.2 «Функция обратного вызова nftw()»). Там функция обратного вызова вызывается для каждого объекта в файловой системе. Здесь функция обратного вызова вызывается для каждого объекта, хранящегося в дереве.

Есть несколько способов прохождения, или «обхода», двоичного дерева:

• Левая вершина, родительская вершина, правая вершина.

• Родительская вершина, левая вершина, правая вершина.

• Левая вершина, правая вершина, родительская вершина.

Функция GLIBC twalk() использует второй способ: сначала родительская вершина, затем левая, затем правая. Каждый раз при встрече с вершиной говорят, что она посещается.[159] В ходе посещения порожденной вершины функция должна посетить и родительскую. Соответственно, значения типа VISIT указывают, на какой стадии произошла встреча с этой вершиной:

preorder   До посещения порожденных.

postorder  После посещения первой, но до посещения второй порожденной вершины.

endorder   После посещения обеих порожденных.

leaf Эта вершина является концевой, не имеющей порожденных вершин.

ЗАМЕЧАНИЕ. Использованная здесь терминология не соответствует точно той, которая используется в формальных руководствах по структурированию данных. Там используются термины inorder, preorder и postorder для обозначения соответствующих трех перечисленных ранее способов прохождения дерева. Таким образом, twalk() использует прохождение по типу preorder, но использует именованные константы preorder и т.д. для обозначения того, на какой стадии была посещена вершина. Это может сбивать с толку.

Следующая программа, ch14-tsearch.c, демонстрирует построение и обход дерева. Она повторно использует структуру struct employee и функцию emp_name_id_compare() из раздела 6.2 «Функции сортировки и поиска».

1  /* ch14-tsearch.c --- демонстрация управления деревом */

2

3  #include <stdio.h>

4  #include <search.h>

5  #include <time.h>

6

7  struct employee {

8   char lastname[30];

9   char firstname[30];

10  long emp_id;

11  time_t start_date;

12 };

13

14 /* emp_name_id_compare --- сравнение по имени, затем no ID */

15

16 int emp_name_id_compare(const void *e1p, const void *e2p)

17 {

18  const struct employee *e1, *e2;

19  int last, first;

20

21  e1 = (const struct employee*)e1p;

22  e2 = (const struct employee*)e2p;

23

24  if ((last = strcmp(e1->lastname, e2->lastname)) != 0)

25   return last;

26

27  /* фамилии совпадают, проверить имена */

28  if ((first = strcmp(e1->firstname, e2->firstname)) != 0)

29   return first;

30

31  /* имена совпадают, проверить ID */

32  if (e1->emp_id < e2->emp_id)

33   return -1;

34  else if (e1->emp_id == e2->emp_id)

35   return 0;

36  else

37   return 1;

38 }

39

40 /* print_emp --- вывод структуры employee во время обхода дерева */

41

42 void print_emp(const void *nodep, const VISIT which, const int depth)

43 {

44  struct employee *e = *((struct employee**)nodep);

45

46  switch (which) {

47  case leaf:

48  case postorder:

49   printf("Depth: %d. Employee: \n", depth);

50   printf("\t%s, %s\t%d\t%s\n", e->lastname, e->firstname,

51    e->emp_id, ctime(&e->start_date));

52   break;

53  default:

54   break;

55  }

56 }

Строки 7–12 определяют struct employee, а строки 14–38 определяют emp_name_id_compare().

Строки 40–56 определяют print_emp(), функцию обратного вызова, которая выводит struct employee наряду с глубиной дерева в текущей вершине. Обратите внимание на магическое приведение типа в строке 44 для получения указателя на сохраненные данные.

58 /* main --- демонстрация хранения данных в двоичном дереве */

59

60 int main(void)

61 {

62 #define NPRES 10

63  struct employee presidents[NPRES];

64  int i, npres;

65  char buf[BUFSIZ];

66  void *root = NULL;

67

68  /* Очень простой код для чтения данных: */

69  for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, stdin) != NULL;

70   npres++) {

71   sscanf(buf, "%s %s %ld %ld\n",

72   presidents[npres].lastname,

73   presidents[npres].firstname,

74   &presidents[npres].emp_id,

75   &presidents[npres].start_date);

76  }

77

78  for (i = 0; i < npres; i++)

79   (void)tsearch(&presidents[i], &root, emp_name_id_compare);

80

81  twalk(root, print_emp);

82  return 0;

83 }

Целью вывода дерева является вывод содержащихся в нем элементов в отсортированном порядке. Помните, что twalk() посещает промежуточные вершины по три раза и что левая вершина меньше родительской, тогда как правая больше. Таким образом, оператор switch выводит сведения о вершине, лишь если which равно leaf, является концевой вершиной, или postorder, что означает, что была посещена левая вершина, а правая еще не была посещена.

Используемые данные представляют собой список президентов, тоже из раздела 6.2 «Функции сортировки и поиска». Чтобы освежить вашу память, полями являются фамилия, имя, номер сотрудника и время начала работы в виде временной отметки в секундах с начала Эпохи:

$ cat presdata.txt

Bush George 43 980013600

Clinton William 42 727552800

Bush George 41 601322400

Reagan Ronald 40 348861600

Carter James 39 222631200

Данные сортируются на основе сначала фамилии, затем имени, а затем старшинства. При запуске[160] программа выдает следующий результат:

$ ch14-tsearch < presdata.txt

Depth: 1. Employee:

Bush, George 41 Fri Jan 20 13:00:00 1989


Depth: 0. Employee:

Bush, George 43 Sat Jan 20 13:00:00 2001


Depth: 2. Employee:

Carter, James 39 Thu Jan 20 13:00:00 1977


Depth: 1. Employee:

Clinton, William 42 Wed Jan 20 13:00:00 1993


Depth: 2. Employee:

Reagan, Ronald 40 Tue Jan 20 13:00:00 1981

14.4.6. Удаление вершины дерева и удаление дерева: tdelete() и tdestroy()

Наконец, вы можете удалить элементы из дерева и, на системах GLIBC, удалить само дерево целиком:

void *tdelete(const void *key, void **rootp,

int (*compare)(const void*, const void*));

/* Расширение GLIBC, в POSIX нет: */

void tdestroy(void *root, void (*free_node)(void *nodep));

Аргументы для tdelete() те же, что и для tsearch(): ключ, адрес корня дерева и функция сравнения. Если в дереве найден данный элемент, он удаляется, и tdelete() возвращает указатель на родительскую вершину. В противном случае возвращается NULL. С этим поведением следует обращаться в своем коде осмотрительно, если вам нужен первоначальный удаляемый элемент, например, для освобождения занимаемой им памяти.

struct employee *е, key; /* Объявления переменных */

void *vp, *root;

/* ...заполнить ключ для удаляемого из дерева элемента... */

vp = tfind(&key, root, emp_name_id_compare); /* Найти удаляемый элемент */

if (vp != NULL) {

 e = *((struct employee**)vp); /* Преобразовать указатель */

 free(e); /* Освободить память */

}

(void)tdelete(&key, &root, emp_name_id_compare); /* Теперь удалить его из дерева */

Хотя это и не указано в справочных страницах или стандарте POSIX, под GNU/Linux, если вы удаляете элемент, хранящийся в корневой вершине, возвращается значение новой корневой вершины. Для переносимого кода не следует полагаться на это поведение

Функция tdestroy() является расширением GLIBC. Она позволяет удалить дерево целиком. Первый аргумент является корнем дерева. Второй является указателем на функцию, которая освобождает данные, на которые указывает каждая вершина дерева. Если с этими данными ничего не надо делать (например, они хранятся в обычном массиве, как в примере нашей программы), эта функция ничего не должна делать. Не передавайте указатель NULL! Это приведет к аварийной ситуации.

14.5. Резюме

• Иногда бывает необходимо выделить память, выровненную по определенной границе. Это осуществляет posix_memalign(). Ее возвращаемое значение отличается от большинства из рассмотренных в данной книге функций. memalign() также выделяет выровненную память, но не все системы поддерживают освобождение памяти с помощью free().

• Блокирование файлов с помощью fcntl() предусматривает блокировку диапазонов, вплоть до блокирования отдельных байтов в файле. Блокировки чтения предотвращают запись в заблокированную область, а блокировки записи предотвращают чтение и запись другими процессами в заблокированную область. По умолчанию используется вспомогательная блокировка, и POSIX стандартизует лишь вспомогательную блокировку. Большинство современных систем Unix поддерживают обязательную блокировку, используя для файла бит setgid прав доступа, а также возможные дополнительные опции монтирования файловой системы.

• GNU/Linux функция lockf() действует в качестве оболочки вокруг блокировки POSIX с помощью fcntl(); блокировки функции BSD flock() совершенно независимы от блокировок fcntl(). Блокировки BSD flock() используются лишь для всего файла в целом и не работают на удаленных файловых системах. По этим причинам использование блокировки flock() не рекомендуется.

• gettimeofday() получает время дня в виде пар (секунды, микросекунды) в struct timeval. Эти значения используются utimes() для обновления времени доступа и модификации файла. Системные вызовы gettimer() и settimer() используют пары struct timeval в struct itimerval для создания интервальных таймеров — сигнальных часов, которые «срабатывают» в установленное время и продолжают срабатывать впоследствии с заданным интервалом. Три различных таймера обеспечивают контроль тех состояний, когда таймер продолжает действовать.

• Функция nanosleep() использует struct timespec, которая указывает время в секундах и наносекундах, чтобы приостановить выполнение процесса в течение определенного интервала времени. У нее есть удачная особенность не взаимодействовать вообще с механизмами сигналов.

• Три API являются стандартным набором функций для хранения и поиска данных, которые сохраняют данные в двоичных деревьях в отсортированном виде. Эти три API очень гибкие, позволяя использовать множество деревьев и произвольные данные.

Упражнения

1. Напишите функцию lockf(), используя fcntl() для осуществления блокировки.

2. Каталог /usr/src/linux/Documentation содержит набор файлов, которые описывают различные аспекты поведения операционной системы. Прочитайте файлы locks.txt и mandatory.txt, чтобы получить больше сведений об обработке Linux блокировок файлов.

3. Запустите на своей системе программу ch14-lockall без обязательной блокировки и посмотрите, сможете ли изменить файл-операнд.

4. Если у вас не-Linux система, поддерживающая обязательную блокировку, попробуйте исполнить на ней программу ch14-lockall.

5. Напишите функцию strftimes() следующего вида:

size_t strftimes(char *buf, size_t size, const char *format,

 const struct timeval *tp);

Она должна вести себя подобно стандартной функции strftime() за тем исключением, что должна использовать %q для обозначения «текущего числа микросекунд».

6. Используя только что написанную функцию strftimes(), напишите расширенную версию date, которая принимает форматирующую строку, начинающуюся с ведущего +, и форматирует текущие дату и время (см. date(1)).

7. Обработка тайм-аута в ch14-timers.c довольно примитивна. Перепишите программу с использованием setjmp() после вывода приглашения и longjmp() из обработчика сигнала. Улучшает ли это структуру или ясность программы?

8. Мы заметили, что ch14-timers.c содержит намеренное состояние гонки. Предположим, пользователь вводит ответ в нужное время, но ch14-timers приостановлена, прежде чем сигнал может быть отменен. Какой вызов вы сделаете, чтобы уменьшить размер проблемного окна?

9. Нарисуйте дерево, как показано в выводе ch14-tsearch в разделе 14.4.5 «Обход дерева: twalk()».

10. Исследуйте файл /usr/share/dict/words на системе GNU/Linux. (Это словарь проверки правописания для spell; на различных системах он может находиться в разных местах.) В файле слова размешены в отсортированном порядке, по одному в строке.

Для начала используйте программу awk для создания нового списка в случайном порядке:

$ awk '{ list[$0]++ }

> END { for (i in list) print i }' /usr/share/dict/words > /tmp/wlist

Далее, напишите две программы. Каждая должна читать новый список и сохранять каждое прочитанное слово в дереве и массиве соответственно. Вторая программа должна использовать для сортировки массива qsort(), а для поиска — bsearch(). Получите из дерева или массива слово 'gravy'. Вычислите время работы двух программ, чтобы увидеть, какая быстрее. Вам может потребоваться заключить получение слова внутрь цикла, повторяющегося множество раз (скажем, 1000), чтобы получить достаточное для определения разницы время.

Используйте вывод ps, чтобы посмотреть, сколько памяти используют программы

11. Повторно запустите обе программы, использовав оригинальный отсортированный словарный файл, и посмотрите, как изменятся временные результаты (если они вообще изменятся).

Часть 3 Отладка и заключительный проект

Глава 15 Отладка

Имеется множество правил, начиная с логики программы и расположения данных, через организацию и расположение кода и кончая реализацией, которые могут минимизировать ошибки и проблемы. Мы рекомендуем вам изучить их; найдите хорошие книги по проектированию и дизайну программного обеспечения и реализуйте содержащиеся там советы на практике! Каждая программа, размером превышающая несколько сот строк кода, должна быть тщательно продумана и спроектирована, а не обтяпана, пока не начнет работать.

Однако, поскольку программисты люди, ошибки программирования неизбежны. Отладка является процессом обнаружения и устранения ошибок в программах. Даже хорошо спроектированные и хорошо реализованные программы иногда не работают; когда что-то идет не так и вы не можете выяснить, почему, хорошей мыслью является нацелить на код отладчик и понаблюдать за появлением ошибки.

Данная глава охватывает ряд тем, начиная с общих методик и советов по отладке (компилирование для отладки и элементарное использование GDB, отладчика GNU), переходя к ряду методик дляиспользования при разработке и отладке программы, упрощающих отладку, и затем рассмотрением ряда инструментов, помогающих в процессе отладки. Глава завершается краткими сведениями по тестированию программного обеспечения и великолепным набором «правил отладки», извлеченных из книги, которую мы весьма рекомендуем.

Большая часть наших советов основана на нашем долгосрочном опыте участия в качестве добровольца в проекте GNU по поддержке gawk (GNU awk). Большинство, если не все, специфические примеры, которые мы представляем, происходят от этой программы. На протяжении главы особые рекомендации помечены словом Рекомендация.

15.1. Сначала главное

Когда программа ведет себя неправильно, вы можете быть в затруднении, что делать сначала. Часто странное поведение возникает из-за неправильного использования памяти — использования неинициализированных значений, чтения или записи за пределами динамической памяти и т.д. Поэтому вы можете быстрее получить результаты, попробовав средства отладки памяти до того, как заведете отладчик.

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

Поскольку отладчик является более универсальным средством, мы рассмотрим его вначале. Далее в главе мы обсудим ряд инструментов для отладки памяти.

15.2. Компиляция для отладки

Для использования отладчика исходного кода, отлаживаемый исполняемый файл должен быть откомпилирован с опцией компилятора -g. Эта опция заставляет компилятор внедрять в объектный код дополнительные отладочные идентификаторы; то есть дополнительные сведения, содержащие имена и типы переменных, констант, функций и так далее. Отладчик затем использует эту информацию для приведения в соответствие местоположения исходного кода с исполняемым кодом и получения или сохранения значений переменных в работающей программе.

На многих системах Unix опция компилятора -g является взаимно исключающей с опцией -O, которая включает оптимизацию. Это потому, что оптимизации могут вызвать перестановку битов и участков объектного кода, так что больше не будет прямого соответствия с тем, что исполняется, и линейным прочтением исходного кода. Отменив оптимизации, вы значительно облегчаете отладчику установление связи между объектным и исходным кодом, и в свою очередь, пошаговое прохождение программы работает очевидным образом. (Пошаговое исполнение вскоре будет описано.)

GCC, GNU Compiler Collection (коллекция компиляторов GNU), на самом деле допускает совместное использование -g и -O. Однако, это привносит как раз ту проблему, которую мы хотим избежать при отладке: следование исполнению в отладчике становится значительно более трудным. Преимуществом совместного использования опций является то, что вы можете оставить отладочные идентификаторы в конечном оптимизированном исполняемом модуле. Они занимают лишь дисковое пространство, а не память. После этого установленный исполняемый файл все еще можно отлаживать при непредвиденных случаях.

По нашему опыту, если нужно использовать отладчик, лучше перекомпилировать приложение с самого начала, использовав лишь опцию -g. Это значительно упрощает трассировку; имеется достаточно деталей, за которыми нужно следить при простом прохождении написанной программы, не беспокоясь о том, как компилятор переставляет код.

Есть одно предостережение: убедитесь, что поведение программы все еще неправильное. Воспроизводимость является ключевой при отладке; если вы не можете воспроизвести проблему, гораздо труднее ее выследить и исправить. В редких случаях компиляция без опции -O может устранить ошибку[161]. Обычно проблема остается при компиляции без использования опции -O, что означает, что на самом деле действительно имеется какая-то разновидность логической ошибки, ждущая своего обнаружения.

15.3. Основы GDB

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

Исторически в V7 Unix был adb, который являлся отладчиком машинного уровня В System III был sdb, который являлся отладчиком исходного кода, a BDS Unix предоставляла dbx, также отладчик исходного кода. (Обе продолжали предоставлять adb.) dbx продолжает существовать на некоторых коммерческих системах Unix.

GDB, отладчик GNU, является отладчиком исходного кода. У него значительно больше возможностей, он значительно более переносим и более практичен, чем любой из sdb или dbx[162].

Как и его предшественники, GDB является отладчиком командной строки. Он выводит по одной строке исходного кода за раз, выдает приглашение и читает одну строку ввода, содержащего команду для исполнения.

Имеются графические отладчики; они предоставляют больший обзор исходного кода и обычно предоставляют возможность манипулировать программой как из окна командной строки, так и через компоненты GUI, такие, как кнопки и меню. Отладчик ddd[163] является одним из таких; он построен поверх GDB, так что если вы изучите GDB, вы сразу же сможете начать использовать ddd. (У ddd есть собственное руководство, которое следует прочесть, если вы собираетесь интенсивно его использовать.) Другим графическим отладчиком является Insight[164], который использует для предоставления поверх GDB графического интерфейса Tcl/Tk. (Следует использовать графический отладчик, если он доступен и нравится вам. Поскольку мы собираемся предоставить введение в отладчики и отладку, мы выбрали использование простого интерфейса, который можно представить в напечатанном виде.)

GDB понимает С и С++, включая поддержку восстановления имен (name demangling), что означает, что вы можете использовать для функций-членов классов и перегруженных функций обычные имена исходного кода С++. В частности, GDB распознает синтаксис выражений С, что полезно при проверке значения сложных выражений, таких, как '*ptr->x.a[1]->q'. Он понимает также Fortran 77, хотя вам может понадобиться добавить к имени функции или переменной Фортрана символ подчеркивания GDB также частично поддерживает Modula-2 и имеет ограниченную поддержку Паскаля.

Если вы работаете на системе GNU/Linux или BSD (и установили средства разработки), у вас, вероятно, уже установлена готовая к использованию последняя версия GDB. Если нет, исходный код GDB можно загрузить с FTP-сайта проекта GNU для GDB[165] и самостоятельно его построить.

GDB поставляется с собственным руководством, которое занимает 300 страниц. В каталоге исходного кода GDB можно сгенерировать печатную версию руководства и самостоятельно его распечатать. Можно также купить в Free Software Foundation (FSF) готовые печатные экземпляры; ваша покупка поможет FSF и непосредственно внесет вклад в производство большего количества свободного программного обеспечения. (Информацию для заказа см. на веб-сайте FSF)[166]. Данный раздел описывает лишь основы GDB; мы рекомендуем прочесть руководство, чтобы научиться использовать все преимущества возможностей GDB.

15.3.1. Запуск GDB

Основное использование следующее:

gdb [опции][исполняемый файл [имя файла дампа]]

Здесь исполняемый файл является отлаживаемой программой. Имя файла дампа, если оно имеется, является именем файла core, созданном при завершении программы операционной системой с созданием снимка процесса. Под GNU/Linux такие файлы (по умолчанию) называются core.pid[167], где pid является ID процесса запущенной программы, которая была завершена. Расширение pid означает, что в одном каталоге могут находиться несколько дампов ядра, что бывает полезно, но также занимает дисковое пространство!

Если вы забыли указать в командной строке имена файлов, для сообщения GDB имени исполняемого файла можно использовать 'file исполняемый-файл', а для имени файла дампа — 'core-file имя-файла-дампа'.

При наличии дампа ядра GDB указывает место завершения программы. Следующая программа, ch15-abort.c, делает несколько вложенных вызовов функций, а затем намеренно завершается посредством abort(), чтобы создать дамп ядра:

/* ch15-abort.c --- создает дамп ядра */

#include <stdio.h>

#include <stdlib.h>


/* recurse --- создание нескольких вызовов функций */

void recurse(void)

{

 static int i;

 if (++i == 3)

  abort();

 else

  recurse();

}


int main(int argc, char **argv)

{

 recurse();

}

Вот небольшой сеанс GDB с этой программой:

$ gcc -g ch15-abort.c -o ch15-abort /* Компилировать без -O */

$ ch15-abort /* Запустить программу */

Aborted (core dumped) /* Она печально завершается */

$ gdb ch15-abort core.4124 /* Запустить для нее GDB */

GNU gdb 5.3

Copyright 2002 Free Software Foundation, Inc.

GDB is free software, covered by the GNU

General Public License, and you are

welcome to change it and/or distribute copies of it

under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "i686-pc-linux-gnu"...

Core was generated by 'ch15-abort'.

Program terminated with signal 6, Aborted.

Reading symbols from /lib/i686/libc.so.6...done.

Loaded symbols for /lib/i686/libc.so.6

Reading symbols from /lib/ld-linux.so.2...done.

Loaded symbols for /lib/ld-linux.so.2

#0 0x42028ccl in kill() from /lib/i686/libc.so.6

(gdb) where /* Вывести трассировку стека */

#0 0x42028cc1 in kill() from /lib/i686/libc.so.6

#1 0x42028ac8 in raise() from /lib/i686/libc.so.6

#2 0x4202a019 in abort() from /lib/1686/libc.so.6

#3 0x08048342 in recurse() at ch15-abort.c:13

 /* <-- Нам нужно исследовать здесь */

#4 0x08048347 in recurse() at ch15-abort.с:15

#5 0x08048347 in recurse() at ch15-abort.c:15

#6 0x0804835f in main (argc=1, argv=0xbffff8f4) at ch15-abort.c:20

#7 0x420158d4 in __libc_start_main() from /lib/i686/libc.so.6

Команда where выводит трассировку стека, то есть список всех вызванных функций, начиная с самых недавних. Обратите внимание, что имеется три вызова функции recurse(). Команда bt, означающая 'back trace' (обратная трассировка), является другим названием для where; ее легче набирать.

Вызов каждой функции в стеке называется фреймом. Этот термин пришел из области компиляторов, в которой параметры, локальные переменные и адреса возврата каждой функции, сгруппированные в стеке, называются фреймом стека. Команда frame GDB дает вам возможность исследовать определенный фрейм. В данном случае нам нужен фрейм 3. Это последний вызов recurse(), который вызвал abort():

(gdb) frame 3 /* Переместиться в фрейм 3 */

#3 0x08048342 in recurse() at ch15-abort.с:13

13 abort(); /* GDB выводит в фрейме положение в исходном коде */

(gdb) list /* Показать несколько строк исходного кода */

8  void recurse(void)

9  {

10  static int i;

11

12  if (++i == 3)

13   abort();

14  else

15   recurse();

16 }

17

(gdb) /* Нажатие ENTER повторяет последнюю команду */

18 int main(int argc, char **argv)

19 {

20  recurse();

21 }

(gdb) quit /* Выйти из отладчика (пока) */

Как показано, нажатие ENTER повторяет последнюю команду, в данном случае list, для отображения строк исходного кода. Это простой способ прохождения исходного кода.

Для редактирования командной строки GDB использует библиотеку readline, поэтому для повторения и редактирования ранее введенных команд можно использовать команды Emacs или vi. Оболочка Bash использует ту же самую библиотеку, поэтому если вам более знакомо редактирование командной строки в приглашении оболочки, GDB работает таким же образом. Эта особенность дает возможность избежать утомительного ручного ввода.

15.3.2. Установка контрольных точек, пошаговое выполнение и отслеживаемые точки

Часто при ошибках программ создается дамп ядра. Первым шагом является использование GDB с файлом core для определения процедуры, в которой произошло завершение программы. Если оригинальный двоичный файл не был откомпилирован для отладки (т.е. без -g), все, что может сообщить GDB, это имя функции, но больше никаких деталей.

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

Контрольная точка (breakpoint) является точкой, в которой исполнение должно прерваться, остановиться. Контрольные точки можно установить по имени функции, номеру строки исходного файла, файлу исходного файла совместно с номером строки, а также другими способами.

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

$ gdb gawk /* Запуск GDB для gawk */

GNU gdb 5.3

...

(gdb) break do_print /* Прерывание в do_print */

Breakpoint 1 at 0x805a36a: file builtin.c, line 1504.

(gdb) run 'BEGIN { print "hello, world" }' /* Запуск программы */

Starting program: /home/arnold/Gnu/gawk/gawk-3.1.3/gawk 'BEGIN { print "hello, world" }'

Breakpoint 1, do_print (tree=0x8095290) at builtin.c:1504

1504 struct redirect *rp = NULL; /* Исполнение достигает контрольной точки */

(gdb) list /* Показать исходный код */

1499

1500 void

1501 do_print(register NODE *tree)

1502 {

1503  register NODE **t;

1504  struct redirect *rp = NULL;

1505  register FILE *fp;

1506  int numnodes, i;

1507  NODE *save;

1508  NODE *tval;

По достижении контрольной точки вы проходите программу в пошаговом режиме. Это означает, что GDB разрешает программе исполнять лишь по одному оператору исходного кода за раз. GDB выводит строку, которую собирается выполнить, и выводит приглашение. Чтобы выполнить оператор, используется команда next:

(gdb) next /* Выполнить текущий оператор (строка 1504 выше) */

1510 fp = redirect_to_fp(tree->rnode, &rp); /* GDB выводит следующий оператор */

(gdb) /* Нажмите ENTER для его выполнения и перехода к следующему */

1511 if (fp == NULL)

(gdb) /* снова ENTER */

1519 save = tree = tree->lnode; (gdb) /* И снова */

1520 for (numnodes = 0; tree != NULL; tree = tree->rnode)

Команда step является альтернативной командой для пошагового исполнения. Между next и step есть важное различие, next выполняет следующий оператор. Если этот оператор содержит вызов функции, эта функция вызывается и возвращается до того, как GDB вернет себе управление от работающей программы.

С другой стороны, когда вы используете с содержащим вызов функции оператором step, GDB входит в вызываемую функцию, позволяя вам продолжить пошаговое исполнение (или трассировку) программы. Если оператор не содержит вызов функции, step аналогична next.

ЗАМЕЧАНИЕ. Легко забыть, какая команда была использована, и продолжать нажимать ENTER для выполнения последующих операторов. Если вы используете step, вы случайно можете войти в библиотечную функцию, такую как strlen() или printf(), с которой на самом деле не хотите возиться. В таком случае можно использовать команду finish, которая вызывает исполнение программы до возврата из текущей функции

Вывести содержимое памяти можно с использованием команды print. GDB распознает синтаксис выражений С, что упрощает и делает естественным проверку структур, на которые ссылаются указатели:

(gdb) print *save /* Вывести структуру, на которую указывает save */

$1 = {sub = {nodep = {l = {lptr = 0x8095250, param_name = 0x8095250 "pR\t\b",

 l1 = 134828624}, r = {rptr = 0x0, pptr = 0, preg = 0x0,

 hd = 0x0, av = 0x0, r_ent =0}, x = {extra = 0x0, x1 = 0,

 param_list = 0x0},

 name = 0x0, number = 1, reflags = 0}, val = {

 fltnum = 6.6614191194446594e-316, sp = 0x0, slen = 0, sref = 1,

 idx = 0}, hash = {next = 0x8095250, name = 0x0, length = 0, value = 0x0,

 ref = 1}}, type = Node_expression_list, flags = 1}

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

1520 for (numnodes = 0; tree != NULL; tree = tree->rnode)

(gdb) cont /* Продолжить *!

Continuing.

hello, world


Program exited normally. /* Сообщение от GDB */

(gdb) quit /* Выйти из отладчика */

Отслеживаемая точка (watchpoint) подобна контрольной точке, но используется для данных, а не для кода. Отслеживаемые точки устанавливаются для переменной (или поля структуры или объединения или элемента массива), при их изменении GDB посылает уведомления. GDB проверяет значение отслеживаемой точки по мере пошагового исполнения программы и останавливается при изменении значения. Например, переменная do_lint_old в gawk равна true, когда была использована опция --lint_old. Эта переменная устанавливается в true функцией getopt_long(). (Мы рассмотрели getopt_long() в разделе 2.1.2 «Длинные опции GNU»). В файле main.c программы gawk:

int do_lint_old = FALSE;

 /* предупредить о материале, не имевшейся в V7 awk */

...

static const struct option optab[] = {

 ...

 { "lint-old", no_argument, &do_lint_old, 1 },

 ...

};

Вот пример сеанса, показывающего отслеживаемую точку в действии:

$ gdb gawk /* Запустить GDB с gawk */

GNU gdb 5.3

...

(gdb) watch do_lint_old

 /* Установить отслеживаемую точку для переменной */

Hardware watchpoint 1: do_lint_old

(gdb) run --lint-old 'BEGIN { print "hello, world" }'

 /* Запустить программу */

Starting program: /home/arnold/Gnu/gawk/gawk-3.1.4/gawk —lint-old

'BEGIN { print "hello, world" }'

Hardware watchpoint 1: do_lint_old

Hardware watchpoint 1: do_lint_old

Hardware watchpoint 1: do_lint_old

 /* Проверка отслеживаемой точки при работе программы */

Hardware watchpoint 1: do_lint_old

Hardware watchpoint 1: do_lint_old

Old value = 0 /* Отслеживаемая точка останавливает программу */

New value = 1

0x420c4219 in _getopt_internal() from /lib/i686/libc.so.6

(gdb) where /* Трассировка стека */

#0 0x420c4219 in _getopt_internal() from /lib/i686/libc.so.6

#1 0x420c4e83 in getopt_long() from /lib/i686/libc.so.6

#2 0x080683a1 in main (argc=3, argv=0xbffff8a4) at main.c:293

#3 0x420158d4 in __libc_start_main() from /lib/i686/libc.so.6

(gdb) quit /* На данный момент мы закончили */

The program is running. Exit anyway? (y or n) y /* Да */

GDB может делать гораздо больше, чем мы здесь показали. Хотя руководство GDB большое, его стоит прочесть целиком хотя бы один раз, чтобы ознакомиться с его командами и возможностями. После этого, возможно, будет достаточно просмотреть файл NEWS в каждом новом дистрибутиве GDB, чтобы узнать, что нового или что изменилось.

Стоит также распечатать справочную карточку GDB, которая поставляется в дистрибутиве GDB в файле gdb/doc/refcard.tex. Создать печатную версию справочной карточки для PostScript после извлечения исходника и запуска configure можно с помощью следующих команд:

$ cd gdb/doc /* Перейти о подкаталог doc */

$ make refcard.ps /* Отформатировать справочную карточку */

Предполагается, что справочная карточка будет распечатана с двух сторон листа бумаги 8,5×11 дюймов[168] (размер «letter») в горизонтальном (landscape) формате. В ней на шести колонках предоставлена сводка наиболее полезных команд GDB. Мы рекомендуем распечатать ее и поместить под своей клавиатурой при работе с GDB.

15.4. Программирование для отладки

Имеется множество методик для упрощения отладки исходного кода, от простых до сложных. В данном разделе мы рассмотрим ряд из них.

15.4.1. Код отладки времени компилирования

Несколько методик относятся к самому исходному коду.

15.4.1.1. Использование отладочных макросов

Возможно, простейшей методикой времени компилирования является использование препроцессора для создания условно компилируемого кода. Например:

#ifdef DEBUG

fprintf(stderr, "myvar = %d\n", myvar);

fflush(stderr);

#endif /* DEBUG */

Добавление -DDEBUG к командной строке компилятора вызывает fprintf() при выполнении программы.

Рекомендация: сообщения отладки посылайте в stderr, чтобы они не были потеряны в канале и чтобы их можно было перехватить при помощи перенаправления ввода/вывода. Убедитесь, что использовали fflush(), чтобы сообщения были выведены как можно скорее

ЗАМЕЧАНИЕ. Идентификатор DEBUG, хотя он и очевидный, также часто злоупотребляется. Лучшей мыслью является использование специфического для вашей программы идентификатора, такого как MYAPPDEBUG. Можно даже использовать различные идентификаторы для отладки кода в различных частях программы, таких, как файловый ввод/вывод, верификация данных, управление памятью и т.д.

Разбрасывание больших количеств операторов #ifdef по всему коду быстро становится утомительным. Большое количество #ifdef скрывают также логику программы. Должен быть лучший способ, и в самом деле, часто используется методика с условным определением специального макроса для вывода:

/* МЕТОДИКА 1 --- обычно используемая, но не рекомендуемая, см. текст */

/* В заголовочном файле приложения: */ #ifdef MYAPPDEBUG

#define DPRINT0(msg) fprintf(stderr, msg)

#define DPRINT1(msg, v1) fprintf(stderr, msg, v1)

#define DPRINT2(msg, v1, v2) fprintf(stderr, msg, v1, v2)

#define DPRINT3(msg, v1, v2, v3) fprintf(stderr, msg, v1, v2, v3)

#else /* ! MYAPPDEBUG */

#define DPRINT0(msg)

#define DPRINT1(msg, v1)

#define DPRINT2(msg, v1, v2)

#define DPRINT3(msg, v1, v2, v3)

#endif /* ! MYAPPDEBUG */


/* В исходном файле приложения: */

DPRINT1("myvar = %d\n", myvar);

...

DPRINT2("v1 = %d, v2 = %f\n", v1, v2);

Имеется несколько макросов, по одному на каждый имеющийся аргумент, число которых определяете вы сами. Когда определен MYAPPDEBUG, вызовы макросов DPRINTx() развертываются в вызовы fprintf(). Когда MYAPPDEBUG не определен, эти вызовы развертываются в ничто. (Так, в сущности, работает assert(); мы описали assert() в разделе 12.1 «Операторы проверки: assert()».)

Эта методика работает; мы сами ее использовали и видели, как ее рекомендуют в учебниках. Однако, она может быть усовершенствована и дальше с уменьшением количества макросов до одного:

/* МЕТОДИКА 2 --- наиболее переносима; рекомендуется */

/* В заголовочном файле приложения: */

#ifdef MYAPPDEBUG

#define DPRINT(stuff) fprintf stuff

#else

#define DPRINT(stuff)

#endif


/* В исходном файле приложения: */

DPRINT((stderr, "myvar = %d\n", myvar));

 /* Обратите внимание на двойные скобки */

Обратите внимание на то, как макрос извлекается с двумя наборами скобок! Поместив весь список аргументов для fprintf() в один аргумент, вам больше не нужно определять произвольное число отладочных макросов.

Если вы используете компилятор, удовлетворяющий стандарту С 1999 г., у вас есть дополнительный выбор, который дает наиболее чистый отладочный код:

/* МЕТОДИКА 3 --- самая чистая, но только для C99 */

/* В заголовочном файле приложения: */

#ifdef MYAPPDEBUG

#define DPRINT(mesg, ...) fprintf(stderr, mesg, __VA_ARGS__)

#else

#define DPRINT(mesg, ...)

#endif


/* В исходном файле приложения: */

DPRINT("myvar = %d\n", myvar);

DPRINT("v1 = %d, v2 = %f\n", v1, v2);

Стандарт С 1999 г. предусматривает варьирующий макрос (variadic macros); т.е. макрос, который может принимать переменное число аргументов. (Это похоже на варьирующую функцию, наподобие printf()). В макроопределении три точки '...' означают, что будет ноль или более аргументов. В теле макроса специальный идентификатор __VA_ARGS__ замещается предусмотренными аргументами, сколько бы их ни было.

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

Рекомендация: Текущие версии GCC поддерживают варьирующие макросы. Таким образом, если вы знаете, что никогда не будете использовать для компилирования своих программ что-то, кроме GCC (или какого-нибудь другого компилятора C99), можете использовать механизм C99. Однако, на момент написания, компиляторы C99 все еще не являются обычным явлением. Поэтому, если ваш код должен компилироваться разными компиляторами, следует использовать макрос в стиле с двумя парами скобок.

15.4.1.2. По возможности избегайте макросов с выражениями

В общем, макросы препроцессора С являются довольно острой палкой с двумя концами. Они предоставляют вам большую мощь, но также и большую возможность пораниться самому.[169]

Обычно для эффективности или ясности можно видеть такие макросы:

#define RS_is_null (RS_node->var_value == Nnull_string)

...

if (RS_is_null || today == TUESDAY) ...

На первый взгляд, он выглядит замечательно. Условие 'RS_is_null' ясно и просто для понимания и абстрагирует внутренние детали проверки. Проблема возникает, когда вы пытаетесь вывести значение в GDB:

(gdb) print RS_is_null

No symbol "RS_is_null" in current context.

В таком случае нужно разыскать определение макроса и вывести развернутое значение.

Рекомендация: Для представления важных условий в своей программе используйте переменные, значения которых при изменении условий явным образом меняется в коде.

Вот сокращенный пример из io.c в дистрибутиве gawk:

void set_RS() {

 ...

 RS_is_null = FALSE;

 if (RS->stlen == 0) {

  ...

  RS_is_null = TRUE;

  ...

  matchrec = rsnullscan;

 }

}

После установки и сохранения RS_is_null ее можно протестировать в коде и вывести из-под отладчика.

ЗАМЕЧАНИЕ. Начиная с GCC 3.1 и версии 5 GDB, если вы компилируете свою программу с опциями -gdwarf-2 и -g3, вы можете использовать макросы из-под GDB. В руководстве по GDB утверждается, что разработчики GDB надеются найти в конце концов более компактное представление для макросов, и что опция -g3 будет отнесена к группе -g.

Однако, использовать макросы таким способам позволяет лишь комбинация GCC, GDB и специальных опций: если вы не используете GCC (или если вы используете более старую версию), у вас все еще есть проблема. Мы придерживаемся своей рекомендации избегать по возможности таких макросов.

Проблема с макросами распространяется также и на фрагменты кода. Если макрос определяет несколько операторов, вы не можете установить контрольную точку в середине макроса. Это верно также для inline-функций C99 и С++: если компилятор заменяет тело inline-функции сгенерированным кодом, снова невозможно или трудно установить внутри него контрольную точку. Это имеет связь с нашим советом компилировать лишь с одной опцией -g; в этом случае компиляторы обычно не используют inline-функции.

Обычно с такими строками используется переменная, представляющая определенное состояние. Довольно просто, и это рекомендуется многими книгами по программированию на С, определять с помощью #define для таких состояний именованные константы. Например:

/* Различные состояния, в которых можно

   находиться при поиске конца записи. */

#define NOSTATE  1 /* сканирование еще не началось (все) */

#define INLEADER 2 /* пропуск начальных данных (RS = "") */

#define INDATA   3 /* в теле записи (все) */

#define INTERM   4 /* терминатор сканирования (RS = RS = regexp) */


int state;

...

state = NOSTATE;

...

state = INLEADER;

...

if (state != INTERM) ...

На уровне исходного кода это выглядит замечательно. Но опять-таки, есть проблема, когда вы пытаетесь просмотреть код из GDB:

(gdb) print state

$1 = 2

Здесь вы также вынуждены возвращаться обратно и смотреть в заголовочный файл, чтобы выяснить, что означает 2. Какова же альтернатива?

Рекомендация: Для определения именованных констант используйте вместо макросов перечисления (enum). Использование исходного кода такое же, а значения enum может выводить также и отладчик.

Пример, тоже из io.c в gawk:

typedef enum scanstate {

 NOSTATE,  /* сканирование еще не начато (все) */

 INLEADER, /* пропуск начальных данных (RS = "") */

 INDATA,   /* в теле записи (все) */

 INTERM,   /* терминатор сканирования (RS = "", RS = regexp) */

} SCANSTATE;

SCANSTATE state;

/* ... остальной код без изменений! ... */

Теперь при просмотре state из GDB мы видим что-то полезное:

(gdb) print state

$1 = NOSTATE

15.4.1.3. При необходимости переставляйте код

Довольно часто условие в if или while состоит из нескольких проверок, разделенных && или ||. Если эти проверки являются вызовами функций (или даже не являются ими), невозможно осуществить пошаговое прохождение каждой отдельной части условия. Команды GDB step и next работают на основе операторов (statements), а не выражений (expressions). (Разнесение их по нескольким строкам все равно не помогает).

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

Вот конкретный пример: функция do_input() из файла io.c gawk:

1  /* do_input --- главный цикл обработки ввода */

2

3  void

4  do_input()

5  {

6   IOBUF *iop;

7   extern int exiting;

8   int rval1, rval2, rval3;

9

10  (void)setjmp(filebuf); /* for 'nextfile' */

11

12  while ((iop = nextfile(FALSE)) != NULL) {

13   /*

14    * Здесь было:

15    if (inrec(iop) == 0)

16     while (interpret(expression_value) && inrec(iop) == 0)

17      continue;

18    * Теперь развернуто для простоты отладки.

19    */

20   rvall = inrec(iop);

21   if (rvall == 0) {

22    for (;;) {

23     rval2 = rval3 = -1; /* для отладки */

24     rval2 = interpret(expression_value);

25     if (rval2 != 0)

26      rval3 = inrec(iop);

27     if (rval2 == 0 || rval3 != 0)

28      break;

29    }

30   }

31   if (exiting)

32    break;

33  }

34 }

(Номера строк приведены относительно начала этой процедуры, а не файла.) Эта функция является основой главного цикла обработки gawk. Внешний цикл (строки 12 и 33) проходит через файлы данных командной строки. Комментарий в строках 13–19 показывает оригинальный код, который читает из текущего файла каждую запись и обрабатывает ее

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

Строки 20–30 представляют переписанный код, который вызывает каждую функцию отдельно, сохраняя возвращаемые значения в локальных переменных, чтобы их можно было напечатать из отладчика. Обратите внимание, как в строке 23 этим переменным каждый раз присваиваются известные, ошибочные значения: в противном случае они могли бы сохранить свои значения от предыдущих итераций цикла. Строка 27 является тестом завершения, поскольку код изменился, превратившись в бесконечный цикл (сравните строку 22 со строкой 16), тест завершения цикла является противоположным первоначальному.

В качестве отступления, мы признаемся, что нам пришлось тщательно изучить переделку, когда мы ее сделали, чтобы убедиться, что она точно соответствует первоначальному коду; она соответствовала. Теперь нам кажется, что, возможно, вот эта версия цикла была бы ближе к оригиналу:

/* Возможная замена для строк 22 - 29 */

do {

 rval2 = rval3 = -1; /* для отладки */

 rval2 = interpret(expression_value);

 if (rval2 != 0)

  rval3 = inrec(iop);

} while (rval2 != 0 && rval3 == 0);

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

Наконец, мы обращаем внимание, что не все программисты-эксперты согласились бы здесь с нашим советом. Когда каждый компонент условия является вызовом функции, можно установить на каждую контрольную точку, использовать step для входа в каждую функцию, а затем использовать finish для ее завершения. GDB сообщит вам возвращаемое функцией значение, и с этого места вы можете использовать для продолжения cont или step. Нам нравится наш подход, поскольку результаты сохраняются в переменных, которые можно проверить (и неоднократно) после вызова функции и даже спустя несколько операторов.

15.4.1.4. Используйте вспомогательные функции отладки

Типичной методикой, применимой во многих случаях, является использование набора значений флагов; когда флаг установлен (т.е. равен true), имеет место определенный факт или применяется определенное условие. Обычно это осуществляется при помощи именованных констант #define и битовых операторов С. (Использование битовых флагов и операторы работы с битами мы обсуждали во врезке к разделу 8.3.1 «Стиль POSIX: statvfs() и fstatvfs()».)

Например, главная структура данных gawk называется NODE. У нее большое количество полей, последнее из которых является набором значений флагов. Из файла awk.h:

typedef struct exp_node {

 /* ... Куча материала опущена */

 unsigned short flags;

#define MALLOC       1 /* может быть освобожден */

#define TEMP         2 /* должен быть освобожден */

#define PERM         4 /* не может быть освобожден */

#define STRING       8 /* назначен в виде строки */

#define STRCUR      16 /* текущее значение строковое */

#define NUMCUR      32 /* текущее значение числовое */

#define NUMBER      64 /* назначен в виде числа */

#define MAYBE_NUM  128 /* ввод пользователя: если NUMERIC, тогда

                        * NUMBER */

#define ARRAYMAXED 256 /* размер массива максимальный */

#define FUNC       512 /* параметр представляет имя функции;

                        * см. awkgram.y */

#define FIELD     1024 /* это является полем */

#define INTLSTR   2048 /* использовать локализованную версию */

} NODE;

Причина для использования значений флагов заключается в том, что они значительно экономят пространство данных. Если бы структура NODE для каждого флага использовала отдельное поле char, потребовалось бы 12 байтов вместо 2, используемых unsigned short. Текущий размер NODE (на Intel x86) 32 байта. Добавление лишних 10 байтов увеличило бы ее до 42 байтов. Поскольку gawk может потенциально выделять сотни и тысячи (или даже миллионы) NODE[170], сохранение незначительного размера является важным.

Что это должно делать с отладкой? Разве мы не рекомендовали только что использовать для именованных констант enum? Ну, в случае объединяемых побитовыми ИЛИ значений enum не помогают, поскольку они больше не являются индивидуально распознаваемыми!

Рекомендация: предусмотрите функцию для преобразования флагов в строки. Если у вас есть несколько независимых флагов, установите процедуру общего назначения.

ЗАМЕЧАНИЕ. Необычность этих функций отладки заключается в том, что код приложения никогда их не вызывает. Они существуют лишь для того, чтобы их можно было вызывать из отладчика. Такие функции всегда должны быть откомпилированы с кодом, даже без окружающих #ifdef, чтобы их можно было использовать. не предпринимая никаких дополнительных шагов. Увеличение (обычно минимальное) размера кода оправдывается экономией времени разработчика

Сначала мы покажем вам, как мы это делали первоначально. Вот (сокращенная версия) flags2str() из ранней версии gawk (3.0.6):

1  /* flags2str --- делает значения флагов удобочитаемыми */

2

3  char *

4  flags2str(flagval)

5  int flagval;

6  {

7   static char buffer[BUFSIZ];

8   char *sp;

9

10  sp = buffer;

11

12  if (flagval & MALLOC) {

13   strcpy(sp, "MALLOC");

14   sp += strlen(sp);

15  }

16  if (flagval & TEMP) {

17   if (sp >= buffer)

18   *sp++ = '|';

19   strcpy(sp, "TEMP");

20   sp += strlen(sp);

21  }

22  if (flagval & PERM) {

23   if (sp != buffer)

24    *sp++ = '|';

25   strcpy(sp, "PERM");

26   sp += strlen(sp);

27  }

    /* ...многое то же самое, опущено для краткости... */

82

83  return buffer;

84 }

(Номера строк даны относительно начала функции.) Результатом является строка, что- то наподобие "MALLOC | PERM | NUMBER". Каждый флаг тестируется отдельно, и если он присутствует, действие каждый раз одно и то же: проверка того, что он не в начале буфера и что можно добавить символ '|', скопировать строку на место и обновить указатель. Сходные функции существовали для форматирования и отображения других видов флагов в программе.

Этот код является повторяющимся и склонным к ошибкам, и для gawk 3.1 мы смогли упростить и обобщить его. Вот как gawk делает это сейчас. Начиная с этого определения в awk.h:

/* для целей отладки */

struct flagtab {

 int val;          /* Целое значение флага */

 const char *name; /* Строковое имя */

};

Эту структуру можно использовать для представления любого набора флагов с соответствующими строковыми значениями. Каждая отдельная группа флагов имеет соответствующую функцию, которая возвращает печатное представление флагов, которые установлены в настоящее время. Из eval.c:

/* flags2str --- делает значения флагов удобочитаемыми */


const char *flags2str(int flagval) {

 static const struct flagtab values[] = {

  { MALLOC, "MALLOC" },

  { TEMP, "TEMP" },

  { PERM, "PERM" },

  { STRING, "STRING" },

  { STRCUR, "STRCUR" },

  { NUMCUR, "NUMCUR" },

  { NUMBER, "NUMBER" },

  { MAYBE_NUM, "MAYBE_NUM" },

  { ARRAYMAXED, "ARRAYMAXED" },

  { FUNC, "FUNC" },

  { FIELD, "FIELD" },

  { INTLSTR, "INTLSTR" },

  { 0, NULL },

 };


 return genflags2str(flagval, values);

}

flags2str() определяет массив сопоставлений флагов со строками. По соглашению, значение флага 0 означает конец массива. Код вызывает для осуществления работы genflags2str() («общий флаг в строку»). getflags2str() является процедурой общего назначения, которая преобразует значение флага в строку. Из eval.c:

1  /* genflags2str --- общая процедура для преобразования значения флага в строковое представление */

2

3  const char *

4  genflags2str(int flagval, const struct flagtab *tab)

5  {

6   static char buffer(BUFSIZ];

7   char *sp;

8   int i, space_left, space_needed;

9

10  sp = buffer;

11  space_left = BUFSIZ;

12  for (i = 0; tab[i].name != NULL; i++) {

13   if ((flagval & tab[i].val) != 0) {

14    /*

15     * обратите внимание на уловку, нам нужны 1 или 0, чтобы

16     * определить, нужен ли нам символ '|'.

17     */

18    space_needed = (strlen(tab[i].name) + (sp != buffer));

19    if (space_left < space_needed)

20     fatal(_("buffer overflow in genflags2str"));

21

22    if (sp >= buffer) {

23     *sp++ = '|';

24     space_left--;

25    }

26    strcpy(sp, tab[i].name);

27    /* обратите внимание на расположение! */

28    space_left -= strlen(sp);

29    sp += strlen(sp);

30   }

31  }

32

33  return buffer;

34 }

(Номера строк приведены относительно начала функции, а не файла.) Как и в предыдущей версии, идея заключалась в заполнении статического буфера строковыми значениями, такими, как "MALLOC | PERM | STRING | MAYBE_NUM", и возвращенииадреса этого буфера. Мы вскоре обсудим причины использования статического буфера; сначала давайте исследуем код.

Указатель sp отслеживает положение следующего пустого слота в буфере, тогда как space_left отслеживает количество оставшегося места; это уберегает нас от переполнения буфера.

Основную часть функции составляет цикл (строка 12), проходящий через массив значений флагов. Когда флаг найден (строка 13), код вычисляет, сколько места требуется строке (строка 18) и проверяет, осталось ли столько места (строки 19–20).

Тест 'sp ! = buffer' для первого значения флага завершается неудачей, возвращая 0. Для последующих флагов тест дает значение 1. Это говорит нам, что между значениями должен быть вставлен разделительный символ '|'. Добавляя результат (1 или 0) к длине строки, мы получаем правильное значение space_needed. Тот же тест с той же целью проводится в строке 22 для проверки строк 23 и 24, которые вставляют символ '|'.

В заключение строки 26–29 копируют значение строки, выверяют количество оставшегося места и обновляют указатель sp. Строка 33 возвращает адрес буфера, который содержит печатное представление строки.

Теперь несколько слов относительно статического буфера. Обычно хорошая практика программирования не одобряет использование функций, возвращающих адреса статических буферов: множественные вызовы таких функций каждый раз переписывают буфер, вынуждая вызывающего копировать возвращенные данные.

Более того, статический буфер по определению является буфером фиксированного размера. Что случилось с принципом GNU «никаких произвольных ограничений»?

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

На практике фиксированный размер также не является проблемой; мы знаем, что размер BUFSIZ достаточен для представления всех флагов, которые мы используем. Тем не менее, поскольку мы опытные и знаем, что вещи могут измениться, в getflags2str() есть код, предохраняющий себя от переполнения буфера. (Переменная space_left и код в строках 18–20.)

В качестве отступления, использование BUFSIZ спорно. Эта константа должна использоваться исключительно для буферов ввода/вывода, но часто она используется также для общих строковых буферов. Такой код лучше убрать, определив явные константы, такие, как FLAGVALSIZE, и использовав в строке 11 'sizeof (buffer)'.

Вот сокращенный сеанс GDB, показывающий использование flags2str():

$ gdb gawk /* Запустить GDB с gawk */

GNU gdb 5.3

...

(gdb) break do_print /* Установить контрольную точку */

Breakpoint 1 at 0x805a584: file builtin.c, line 1547.

(gdb) run 'BEGIN { print "hello, world" }' /* Запустить программу */

Starting program: /home/arnold/Gnu/gawk/gawk-3.1.4/gawk 'BEGIN { print "hello, world" }'

Breakpoint 1, do_print (tree=0x80955b8) at builtin.c: 1547 /* Останова в контрольной точке */

1547 struct redirect *rp = NULL;

(gdb) print *tree /* Вывести NODE */

$1 = {sub = {nodep =

 {1 = {lptr = 0x8095598, param_name = 0x8095598 "xU\t\b",

 ll = 134629464}, r = {rptr = 0x0, pptr = 0, preg = 0x0, hd = 0x0,

 av = 0x0, r_ent =0}, x = {extra = 0x0, xl = 0, param_list = 0x0},

 name = 0x0, number = 1, reflags = 0), val = {

 fltnum = 6.6614606209589101e-316, sp = 0x0, slen = 0, sref = 1,

 idx = 0}, hash = {next = 0x8095598, name = 0x0, length = 0, value = 0x0,

 ref = 1}}, type = Node_K_print, flags = 1}

(gdb) print flags2str(tree->flags) /* Вывести значение флага */

$2 = 0x80918a0 "MALLOC"

(gdb) next /* Продолжить */

1553 fp = redirect_to_fp(tree->rnode, &rp);

...

1588 efwrite(t[i]->stptr, sizeof(char), t[i]->stlen, fp, "print", rp, FALSE);

(gdb) print *t[i] /* Снова вывести NODE */

$4 = {sub = {nodep =

 {l = {lptr = 0x8095598, parm_name = 0x8095598 "xU\t\b",

 ll = 134829464}, r = {rptr = 0x0, pptr = 0, preg = 0x0, hd = 0x0,

 av = 0x0, r_ent =0), x = {extra = 0x8095ad8, xl = 134830808,

 param_list = 0x8095ad8}, name = 0xc <Address 0xc out of bounds>,

 number = 1, reflags = 4294967295}, val = {

 fltnum = 6.6614606209589101e-316, sp = 0x8095ad8 "hello, world",

 slen = 12, sref = 1, idx = -1}, hash = {next = 0x8095598, name = 0x0,

 length = 134830808, value = 0xc, ref = 1}}, type = Node_val, flags = 29}

(gdb) print flags2str(t[i]->flags) /* Вывести значение флага */

$5 = 0x80918a0 "MALLOC|PERM|STRING|STRCUR"

Надеемся, вы согласитесь, что настоящий механизм общего назначения значительно более элегантный и более простой в использовании, чем первоначальный.

Тщательное проектирование и использование массивов структур часто может заменить или слить воедино повторяющийся код.

15.4.1.5. По возможности избегайте объединений

«Не бывает бесплатных обедов»

- Lazarus Long -
union С относительно эзотерическая возможность. Она помогает экономить память, сохраняя различные элементы в одном и том же физическом пространстве; как программа интерпретирует его, зависит от способа доступа:

/* ch15-union.c --- краткая демонстрация использования union. */

#include <stdio.h>


int main(void) {

 union i_f {

  int i;

  float f;

 } u;


 u.f = 12.34; /* Присвоить значение с плавающей точкой */

 printf("%f also looks like %#x\n", u.f, u.i};

 exit(0);

}

Вот что происходит, когда программа запускается на системе Intel x86 GNU/Linux:

$ ch15-union

12.340000 also looks like 0x414570a4

Программа выводит битовый паттерн, который представляет число с плавающей точкой в виде шестнадцатеричного целого. Оба поля занимают одно и то же место в памяти; разница в том, как этот участок памяти интерпретируется: u.f действует, как число с плавающей точкой, тогда как эти же биты в u.i действуют, как целое число.

Объединения особенно полезны в компиляторах и интерпретаторах, которые часто создают древовидные структуры, представляющие структуру файла с исходным кодом (которая называется деревом грамматического разбора (parse tree)). Это моделирует то, как формально описаны языки программирования: операторы if, операторы while, операторы присваивания и так далее для всех экземпляров более общего типа «оператора». Таким образом, в компиляторе могло бы быть нечто подобное этому:

struct if_stmt { ... }; /* Структура для оператора IF */

struct while_stmt { ... }; /* Структура для оператора WHILE */

struct for_stmt { ... }; /* Структура для оператора */

/* ...структуры для других типов операторов... */


typedef enum stmt_type {

 IF, WHILE, FOR, ...

} TYPE; /* Что у нас есть в действительности */

/* Здесь содержатся тип и объединения отдельных видов операторов. */

struct statement {

 TYPE type;

 union stmt {

  struct if_stmt if_st;

  struct while_stmt while_st;

  struct for_stmt for_st;

  ...

 } u;

};

Вместе с объединением удобно использовать макрос, который представляет компоненты объединения, как если бы они были полями структуры. Например:

#define if_s u.if_st /* Так что можно использовать s->if_s вместо s->u.if_st */

#define while_s u.while_st /* И так далее... */

#define for_s u.for_st

...

На только что представленном уровне это кажется разумным и выглядит осуществимым. В действительности, однако, все сложнее, и в реальных компиляторах и интерпретаторах часто есть несколько уровней вложенных структур и объединений. Сюда относится и gawk, в котором определение NODE, значение его флагов и макросов для доступа к компонентам объединения занимают свыше 120 строк![171] Здесь достаточно определений, чтобы дать вам представление о том, что происходит:

typedef struct exp_node {

 union {

  struct {

   union {

    struct exp_node *lptr;

    char *param_name;

    long ll;

   } l;

   union {

    ...

   } r;

   union {

    ...

   } x;

   char *name;

   short number;

   unsigned long reflags;

   ...

  } nodep;

  struct {

   AWKNUM fltnum;

   char *sp;

   size_t slen;

   long sref;

   int idx;

  } val;

  struct {

   struct exp_node *next;

   char *name;

   size_t length;

   struct exp_node *value;

   long ref;

  } hash;

#define hnext sub.hash.next

#define hname sub.hash.name

#define hlength sub.hash.length

#define hvalue sub.hash.value

  ...

 } sub;

 NODETYPE type;

 unsigned short flags;

 ...

} NODE;


#define vname sub.nodep.name

#define exec_count sub.nodep.reflags


#define lnode sub.nodep.l.lptr

#define nextp sub.nodep.l.lptr

#define source_file sub.nodep.name

#define source_line sub.nodep.number

#define param_cnt sub.nodep.number

#define param sub.nodep.l.param_name


#define stptr sub.val.sp

#define stlen sub.val.slen

#define stref sub.val.sref

#define stfmt sub.val.idx

#define var_value lnode

...

В NODE есть объединение внутри структуры внутри объединения внутри структуры! (Ой.) Поверх всего этого многочисленные «поля» макросов соответствуют одним и тем же компонентам struct/union в зависимости от того, что на самом деле хранится в NODE! (Снова ой.)

Преимуществом такой сложности является то, что код С сравнительно ясный. Нечто вроде 'NF_node->var_value->slen' читать просто.

У такой гибкости, которую предоставляют объединения, конечно, есть своя цена. Когда отладчик находится глубоко во внутренностях вашего кода, вы не можете использовать симпатичные макросы, которые имеются в исходном коде. Вы должны использовать развернутое значение.[172] (А для этого придется найти в заголовочном файле соответствующее определение.)

Например, сравните 'NF_node->var_value->slen' с развернутой формой: 'NF_node->sub.nodep.l.lptr->sub.val.slen'! Чтобы увидеть значение данных, вы должны набрать последнее в GDB. Взгляните снова на это извлечение из приведенного ранее сеанса отладки GDB:

(gdb) print *tree /* Вывести NODE */

$1 = {sub = {nodep =

 {1 = {lptr = 0x8095598, param_name = 0x8095598 "xU\t\b",

 ll = 134829464}, r = {rptr = 0x0, pptr = 0, preg = 0x0,

 hd = 0x0, av = 0x0, r_ent =0), x = {extra = 0x0, xl = 0,

 param_list = 0x0}, name = 0x0, number = 1, reflags = 0},

 val = { fltnum = 6.6614606209589101e-316, sp = 0x0,

 slen = 0, sref = 1, idx = 0),

 hash = {next = 0x8095598, name = 0x0, length = 0,

 value = 0x0, ref = 1}}, type = Node_K_print, flags = 1}

Это куча вязкой массы. Однако, GDB все же несколько упрощает ее обработку. Вы можете использовать выражения вроде '($1).sub.val.slen', чтобы пройти через дерево и перечислить структуры данных.

Есть другие причины для избегания объединений. Прежде всего, объединения не проверяются. Ничто, кроме внимания программиста, не гарантирует, что когда вы получаете доступ к одной части объединения, вы получаете доступ к той части, которая была сохранена последней. Мы видели это в ch15-union.c, в котором доступ к обоим «элементам» объединения осуществлялся одновременно.

Вторая причина, связанная с первой, заключается в осторожности с перекрытиями вложенных комбинаций struct/union. Например, в предыдущей версии gawk[173] был такой код.

/* n->lnode перекрывает размер массива, не вызывайте unref, если это массив */

if (n->type != Node_var_array && n->type != Node_array_ref)

unref(n->lnode);

Первоначально if не было, был только вызов unref(), которая освобождает NODE, на которую указывает n->lnode. Однако, в этот момент gawk могла создать аварийную ситуацию. Можете себе представить, сколько времени потребовало отслеживание в отладчике того факта, что то, что рассматривалось как указатель, на самом деле было размером массива!

В качестве отступления, объединения значительно менее полезны в С++. Наследование и объектно-ориентированные возможности создают при управлении структурами данных совсем другую ситуацию, которая значительно безопаснее.

Рекомендация: по возможности избегайте объединений (union). Если это невозможно, тщательно проектируйте и программируйте их!

15.4.2. Отлаживаемый код времени исполнения

Помимо тех вещей, которые вы добавляете к своему коду для времени компиляции, можно также добавить дополнительный код для обеспечения возможностей отладки времени исполнения. Это особенно полезно для приложений, которые устанавливаются в полевых условиях, когда в системе клиента не будет установленного исходного кода (а может быть, даже и компилятора!)

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

15.4.2.1. Добавляйте отладочные опции и переменные

Простейшей методикой является наличие опции командной строки, делающих возможным отладку. Такая опция может быть условно откомпилированной для отладки. Однако более гибким подходом является оставить опцию в готовой версии программы. (Вы можете также решить, оставлять или не оставлять эту опцию не документированной. Здесь есть различные компромиссы: ее документирование может дать возможность вашим покупателям или клиентам больше изучить внутренности вашей системы, чего вы можете не хотеть С другой стороны, не документирование ее кажется довольно подлым. Если вы пишете для Open Source или Free Software, лучше документировать опцию.)

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

struct option options[] = {

 ...

 { "debug", required_argument, NULL, 'D' },

 ...

};


int main(int argc, char **argv) {

 int c;


 while ((c = getopt_long(argc, argv, "...D:")) != -1) {

  switch (c) {

   ...

  case 'D':

   parse_debug(optarg);

   break;

   ...

  }

 }

 ...

}

Функция parse_debug() считывает строку аргументов. Например, это может быть строка разделенных запятыми или пробелами подсистем, вроде "file,memory,ipc". Для каждого действительного имени подсистемы функция устанавливает бит в отладочной переменной:

extern int debugging;

void parse_debug(const char *subsystems) {

 char *sp;

 for (sp = subsystems; *sp != '\0';) {

  if (strncmp(sp, "file", 4) == 0) {

   debugging |= DEBUG_FILE;

   sp += 4;

  } else if (strncmp(sp, "memory", 6) == 0) {

   debugging |= DEBUG_MEM;

   sp += 6;

  } else if (strncmp(sp, "ipc", 3) == 0) {

   debugging |= DEBUG_IPC;

   sp += 3;

   ...

  }

  while (*sp == ' ' || *sp == ',') sp++;

 }

}

В конечном счете код приложения может затем проверить флаги:

if ((debugging & DEBUG_FILE) != 0) ...

 /* В части программы для ввода/вывода */


if ((debugging & DEBUG_MEM) != 0) ... /* В менеджере памяти */

Использовать ли одну переменную с флаговыми битами, различные переменные или даже отладочный массив, индексируемый именованными константами (желательно из enum), зависит от вас.

Ценой оставления отладочного кода в исполняемом файле изделия является увеличение размера программы. В зависимости от размещения отладочного кода он может быть также более медленным, поскольку каждый раз осуществляются проверки, которые все время оказываются ложными, пока не будет включен режим отладки. И, как упоминалось, кто-нибудь может изучить вашу программу, что может быть неприемлемым для вас. Или еще хуже, недоброжелательный пользователь может включить столько отладочных возможностей, что программа замедлится до невозможности работать с ней! (Это называется атакой отказа в обслуживании (denial of service attack).)

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

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

15.4.2.2. Используйте специальные переменные окружения

Другой полезной уловкой является проверка вашим приложением специальных переменных окружения (документированных или иных). Это может быть особенно полезным для тестирования. Вот другой пример из нашего опыта с gawk, но сначала немного основ.

gawk использует функцию с названием optimal_bufsize() для получения оптимального размера буфера для ввода/вывода. Для небольших файлов функция возвращает размер файла. В противном случае, если файловая система определяет размер для использования при вводе/выводе, возвращается это значение (член st_blksize структуры struct stat, см. раздел 5.4.2 «Получение информации о файле»). Если этот член недоступен, optimal_bufsize() возвращает константу BUFSIZ из <stdio.h>. Оригинальная функция (в posix/gawkmisc.c) выглядела следующим образом:

1  /* optimal_bufsize --- определяет оптимальный размер буфера */

2

3  int

4  optimal_bufsize(fd, stb) /* int optimal_bufsize(int fd, struct stat *stb); */

5  int fd;

6  struct stat *stb;

7  {

8   /* инициализировать все члены нулями на случай, если ОС не использует их все. */

9   memset(stb, '\0', sizeof(struct stat));

10

11 /*

12  * System V.n, n < 4, не имеет в структуре stat размера

13  * системного блока файла. Поэтому нам нужно сделать разумную

14  * догадку. Мы используем BUFSIZ, поскольку именно это имелось

15  * в виду на первом месте.

16  */

17 #ifdef HAVE_ST_BLKSIZE

18 #define DEFBLKSIZE (stb->st_blksize ? stb->st_blksize : BUFSIZ)

19 #else

20 #define DEFBLKSIZE BUFSIZ

21 #endif

22

23  if (isatty(fd))

24   return BUFSIZ;

25  if (fstat(fd, stb) == -1)

26   fatal("can't stat fd %d (%s)", fd, strerror(errno));

27  if (lseek(fd, (off_t)0, 0) == -1) /* не обычный файл */

28   return DEFBLKSIZE;

29  if (stb->st_size > 0 && stb->st_size < DEFBLKSIZE) /* маленький файл */

30   return stb->st_size;

31  return DEFBLKSIZE;

32 }

Константа DEFBLKSIZE является «размером блока по умолчанию»; то есть значением из struct stat или BUFSIZ. Для терминалов (строка 23) или файлов, которые не являются обычными файлами (lseek() завершается неудачей, строка 27) возвращаемое значение также равно BUFSIZ. Для небольших обычных файлов используется размер файла. Во всех других случаях возвращается DEFBLKSIZE. Знание «оптимального» размера буфера особенно полезно в файловых системах, в которых размер блока больше BUFSIZ.

У нас была проблема, когда один из наших контрольных примеров отлично работал на нашей рабочей системе GNU/Linux и на любой другой системе Unix, к которой у нас был доступ. Однако, этот тест последовательно терпел неудачу на других определенных системах.

В течение длительного времени мы не могли получить непосредственный доступ к терпящей неудачу системе, чтобы запустить GDB. В конце концов, мы смогли, однако, ухитриться воспроизвести проблему. Она оказалась связана с размером буфера, который gawk использовал для чтения файлов данных: на терпящих неудачи системах размер буфера был больше, чем на нашей системе разработки.

Нам был нужен способ воспроизведения проблемы на своей машине разработки, система с неудачей находилась в стороне за девять часовых поясов, а интерактивный запуск GDB через Атлантический океан мучителен. Мы воспроизвели проблему, заставив optimal_bufsize() проверять значение специальной переменной окружения AWKBUFSIZE. Когда ее значение равно "exact", optimal_bufsize() всегда возвращает размер файла, каким бы он ни был. Если значением AWKBUFSIZE является какое-нибудь целое число, функция возвращает это число. В противном случае, функция возвращается к прежнему алгоритму. Это дает нам возможность запускать тесты, не требуя постоянной перекомпиляции gawk. Например,

$ AWKBUFSIZE=42 make check

Это запускает тестовый набор gawk с использованием размера буфера в 42 байта. (Тестовый набор проходит.) Вот модифицированная версия optimal_bufsize():

1  /* optimal_bufsize --- определение оптимального размера буфера */

2

3  /*

4   * В целях отладки усовершенствуйте это следующим образом:

5   *

6   * Всегда используйте stat для файла, буфер stat используется кодом

7   * более высокого уровня.

8   * if (AWKBUFSIZE == "exact")

9   *  return the file size

10  * else if (AWKBUFSIZE == число)

11  *  всегда возвращать это число

12  * else

13  *  if размер < default_blocksize

14  *   return размер

15  *  else

16  *   return default_blocksize

17  *  end if

18  * end if

19  *

20  * Приходится повозиться, чтобы иметь дело с AWKBUFSIZE лишь

21  * однажды, при первом вызове этой процедуры, а не при каждом

22  * ее вызове. Производительность, знаете ли.

23  */

24

25 size_t

26 optimal_bufsize(fd, stb)

27 int fd;

28 struct stat *stb;

29 {

30  char *val;

31  static size_t env_val = 0;

32  static short first = TRUE;

33  static short exact = FALSE;

34

35  /* обнулить все члены, на случай, если ОС их не использует. */

36  memset(stb, '\0', sizeof(struct stat));

37

38  /* всегда использовать stat на случай, если stb используется кодом более высокого уровня */

39  if (fstat(fd, stb) == -1)

40   fatal("can't stat fd %d (%s)", fd, strerror(errno));

41

42  if (first) {

43   first = FALSE;

44

45   if ((val = getenv("AWKBUFSIZE")) != NULL) {

46    if (strcmp(val, "exact") == 0)

47     exact = TRUE;

48    else if (ISDIGIT(*val)) {

49     for (; *val && ISDIGIT(*val); val++)

50     env_val = (env_val * 10) + *val - '0';

51

52     return env_val;

53    }

54   }

55  } else if (!exact && env_val > 0)

56   return env_val;

57  /* else

58     обрабатывать дальше */

59

60  /*

61   * System V.n, n < 4, не имеет в структуре stat размера системного

62   * блока файла. Поэтому нам нужно осуществить разумную догадку.

63   * Мы используем BUFSIZ из stdio, поскольку именно это имелось

64   * в виду прежде всего.

65   */

66 #ifdef HAVE_ST_BLKSIZE

67 #define DEFBLKSIZE (stb->st_blksize > 0 ? stb->st_blksize : BUFSIZ)

68 #else

69 #define DEFBLKSIZE BUFSIZ

70 #endif

71

72  if (S_ISREG(stb->st_mode) /* обычный файл */

73   && 0 < stb->st_size /* ненулевой размер */

74   && (stb->st_size < DEFBLKSIZE /* маленький файл */

75   || exact)) /* или отладка */

76   return stb->st_size; /* использовать размер файла*/

77

78  return DEFBLKSIZE;

79 }

Комментарий в строках 3–23 объясняет алгоритм. Поскольку поиск переменных окружения может быть затратным и его нужно осуществить лишь однажды, функция использует для сбора соответствующих сведений в первый раз несколько статических переменных.

Строки 42–54 выполняются лишь при первом вызове функции. Строка 43 обеспечивает это условие, устанавливая в first значение false. Строки 45–54 обрабатывают переменную окружения, разыскивая либо строку "exact", либо число. В последнем случае оно преобразуется из строкового значения в десятичное, сохраняясь в env_val. (Возможно, нам следовало бы использовать здесь strtoul(); в свое время это не пришло нам на ум.)

Строка 55 выполняется каждый раз, кроме первого. Если было представлено числовое значение, условие будет истинным, и возвращается это значение (строка 56). В противном случае, исполнение переходит к оставшейся части функции.

Строки 60–70 определяют DEFBLKSIZE; эта часть не изменилась. Наконец, строки 72–76 возвращают размер файла, если это приемлемо. Если нет (строка 78), возвращается DEGBLKSIZE.

Мы действительно устранили проблему[174], но между тем оставили на месте новую версию optimal_bufsize(), чтобы можно было убедиться, что проблема не возникнет вновь.

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

15.4.2.3. Добавьте код журналирования

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

• Всегда записывайте сведения в специфический файл. Это простейший способ: программа всегда записывает регистрационную информацию. Затем вы можете при возможности просмотреть файл.

Недостаток в том, что в какой-то момент регистрационный файл займет все дисковое пространство. Следовательно, у вас должны быть несколько файлов журналов, причем программа периодически должна переключаться между ними. Брайан Керниган рекомендует называть файлы журнала по дням недели: myapp.log.sun, myapp.log.mon и т.д. Преимуществом здесь является то, что вам не придется вручную удалять старые файлы; вы бесплатно получаете недельную стоимость файлов журналов.

• Записывайте в файл журнала лишь тогда, когда он уже существует. При запуске ваша программа записывает сведения в файл журнала, если он существует. В противном случае записи не происходит. Чтобы включить журналирование, сначала создайте пустой файл журнала.

• Используйте для сообщений фиксированный формат, который можно легко анализировать с помощью языков сценариев, таких, как awk или Perl, для создания сводок и отчетов.

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

• Для журналирования используйте syslog(); конечное расположение сообщений журналирования может контролироваться системным администратором, (syslog() является довольно продвинутым интерфейсом; см. справочную страницу syslog(3)).

Выбор того, как регистрировать сведения, является, конечно, легкой частью. Трудной частью является выбор того, что регистрировать. Как и в остальных случаях разработки программ, стоит подумать, прежде чем программировать. Записывайте сведения о критических переменных. Проверьте их значения, чтобы убедиться, что они в приемлемом диапазоне или в других отношениях ведут себя, как ожидается. Записывайте исключительные условия; если появляется что-то, что не должно было, зарегистрируйте это и при возможности продолжайте исполнение.

Ключом является регистрация лишь тех сведений, которые вам нужны для отслеживания проблем, не больше и не меньше.

15.4.2.4. Файлы отладки времени исполнения

В предыдущей жизни мы работали для начинающей компании с двоичными исполняемыми файлами продукта, установленными на сайтах клиентов. Подключить отладчик к запущенной копии программы или запустить ее из отладчика на системе клиента было невозможно. Главный компонент продукта запускался не непосредственно из командной строки, а опосредованно, через сценарии оболочки, которые проделывали значительную первоначальную настройку.

Чтобы заставить программу выдавать при запуске журналируемые сведения, мы пришли к идее специальных отладочных файлов. Когда файл с определенным именем находился в определенном каталоге, программа выдавала бы информационные сообщения в файл журнала, который мы могли бы затем загрузить и проанализировать. Такой код выглядит следующим образом:

struct stat sbuf;

extern int do_logging; /* инициализировано нулями */


if (stat("/path/to/magic/.file", &sbuf) == 0)

 do_logging = TRUE;

...

if (do_logging) {

 /* здесь код журналирования: открытие файла, запись, закрытие и

  * т.д. * /

}

Вызов stat() происходил для каждого задания, которое выполняла программа. Таким образом, мы могли динамически включать и отключать журналирование без необходимости останавливать и повторно запускать приложение!

Как и в случае с отладочными опциями и переменными, в этом предмете имеется множество вариаций: различные файлы, которые запускают журналирование информации о различных подсистемах, директивы отладки, добавляемые в сам отладочный файл и т.д. Как и со всеми возможностями, следует планировать схему того, что вам будет нужно, а затем чисто ее реализовывать, вместо того, чтобы набросать какой-нибудь быстрый и грязный код в 3 часа пополудни (к сожалению, довольно типичная возможность в начинающих компаниях).

ЗАМЕЧАНИЕ. Не все то золото, что блестит. Специальные отладочные файлы являются лишь одним примером методик, известных как лазейки (back doors) — один или более способов выполнения разработчиками недокументированных вещей с программой, обычно с бесчестными намерениями. В нашем примере лазейка была исключительно доброкачественной. Но беспринципный разработчик легко мог бы устроить создание и загрузку скрытой копии списка клиентов, картотеки персонала или других важных данных. По одной этой причине вы должны серьезно подумать, применима ли эта методика в вашем приложении.

15.4.2.5. Добавьте специальные ловушки для контрольных точек

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

Это большая проблема, когда вы работаете в отладчике. Если вы установите контрольную точку на вызывающую сбой процедуру, вам придется набирать команду continue и нажимать ENTER сотни или тысячи раз, чтобы привести программу в состояние перед сбоем. Это по меньшей мере утомительно и способствует появлению ошибок! Это может оказаться даже таким трудным, что вы захотите отказаться от этого, даже не начав.

Решение заключается в добавлении специальных отладочных функций «ловушек» («hook»), которые ваша программа может вызвать при приближении к интересующему вас состоянию.

Например, предположим, что вы знаете, что функция check_salary() вызывает сбой, но лишь когда она вызвана 1427 раз. (Мы не смеемся над вами; в свое время нам пришлось наблюдать довольно странные вещи.)

Чтобы перехватить check_salary() до того, как она завершится неудачей, создайте специальную фиктивную функцию, которая ничего не делает и просто возвращается, затем сделайте так, чтобы check_salary() вызывала ее как раз перед 1427-м своим вызовом:

/* debug_dummy --- отладочная функция-ловушка */

void debug_dummy(void) { return; }


struct salary *check_salary(void) {

 /* ...здесь описания настоящих переменных... */

 static int count = 0; /* для отладки */

 if (++count == 1426)

  debug_dummy();

 /* ...оставшаяся часть кода... */

}

Теперь из GDB установите контрольную точку в debug_dummy(), а затем запустите программу обычным способом:

(gdb) break debug_dummy /* Установить контрольную точку для фиктивной функции */

Breakpoint 1 at 0x8055885: file whizprog.c, line 3137.

(gdb) run /* Запуск программы */

По достижении контрольной точки для debug_dummy() вы можете установить вторую контрольную точку для check_salary() и продолжить исполнение:

(gdb) run /* Запуск программы */

Starting program: /home/arnold/whizprog


Breakpoint 1, debug_dummy() at whizprog.c, line 3137

3137 void debug_dummy(void) { return; } /* Достижение контрольной точки */

(gdb) break check_salary

 /* Установить контрольную точку для интересующей функции */

Breakpoint 2 at 0x8057913: file whizprog.c, line 3140.

(gdb) cont

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

Вместо использования фиксированной константы ('++count == 1426') можно использовать глобальную переменную, которая устанавливается отладчиком в любое нужное вам значение. Это дает возможность избежать перекомпилирования программы

Для gawk мы пошли на один шаг дальше и внесли возможность отладочной ловушки в язык, так что функция ловушки могла быть вызвана из программы awk. При компилировании для отладки доступна специальная ничего не делающая функция stopme(). Эта функция, в свою очередь, вызывает функцию С с тем же названием. Это позволяет нам поместить вызовы stopme() в завершающуюся неудачей программу awk непосредственно перед сбойным участком. Например, если gawk выдает ошибочные результаты для программы awk в 1200-й вводимой записи, мы можем добавить в программу awk строку, подобную этой:

NR == 1198 { stopme() } # Остановиться для отладки, когда число записей == 1198

/* ...оставшаяся часть программы как ранее... */

Затем из GDB мы можем установить контрольную точку на функции С stopme() и запустить программу awk. Когда контрольная точка срабатывает, мы можем затем установить контрольные точки на другие части gawk, где, как мы ожидаем, находится действительная проблема.

Методика функции-ловушки полезна сама по себе. Однако, возможность переместить ее на уровень приложения умножает ее полезность, и она сохранила нам бесчисленное число часов отладки при отслеживании непонятных проблем.

15.5. Отладочные инструменты

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

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

15.5.1. Библиотека dbug — усовершенствованный printf()

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

Библиотека dbug, написанная Фредом Фишем (Fred Fish) в начале 1980-х, была с тех пор несколько усовершенствована. Теперь она явным образом является общим достоянием, поэтому ее можно использовать без всяких проблем как в свободном, так и частном программном обеспечении. Она доступна через архив FTP Фреда Фиша[175] как в виде сжатого файла tar, так и в виде архива ZIP. Документация хорошо резюмирует dbug:

dbug является примером внутреннего отладчика. Поскольку она требует внутренней поддержки программы и ее использование не зависит от каких бы то ни было особых возможностей среды исполнения, она всегда доступна и будет выполняться в любом окружении, в котором будет выполняться сама программа. Вдобавок, поскольку это законченный пакет с особым интерфейсом пользователя, все программы, которые ее используют, будут иметь сходные возможности отладки. Это резко контрастирует с другими формами внутренней поддержки, где у каждого разработчика своя собственная, обычно менее квалифицированная, форма внутреннего отладчика...

Пакет dbug лишь незначительно снижает скорость выполнения программ, обычно значительно менее 10%, и немного увеличивает их размеры, обычно от 10 до 20%. Определив особый идентификатор препроцессора С, можно снизить оба этих показателя до нуля без необходимости изменений в исходном коде.

Следующий список является кратким изложением возможностей пакета dbug. Каждую возможность можно отдельно включать или отключать во время запуска программы, указав соответствующие аргументы командной строки.

• Трассировка исполнения, отображающая уровень потока управления полуграфическим способом с использованием отступов, обозначающих глубину вложения

• Вывод значений всех или любого набора ключевых внутренних переменных.

• Ограничение действий определенным набором указанных функций.

• Ограничение трассировки функций указанной глубиной вложения.

• Пометку каждой выводимой строки названием исходного файла и номером строки.

• Пометку каждой выводимой строки названием текущего процесса.

• Сохранение в стеке или восстановление состояния отладки для обеспечения исполнения со встроенными значениями по умолчанию для отладки.

• Перенаправление потока вывода отладки в стандартный вывод (stdout) или указанный файл. По умолчанию поток вывода направляется в стандартную ошибку (stderr). Механизм перенаправления полностью независим от обычного перенаправления командной строки, чтобы избежать конфликтов вывода.

Пакет dbug требует от вас использования определенного порядка при написании своего кода. В частности, нужно использовать его макросы при возвращении из функции или вызове setjmp() и longjmp(). Нужно добавлять один вызов макроса в качестве первого исполняемого оператора каждой функции и вызвать несколько дополнительных макросов из main(). Наконец, нужно добавить отладочную опцию командной строки, по соглашению, это -#, которая редко используется в качестве действительной опции, если вообще используется. В обмен на дополнительную работу вы получаете все только что очерченные преимущества. Давайте взглянем на пример в руководстве:

1  #include <stdio.h>

2  #include "dbug.h"

3

4  int

5  main(argc, argv)

6  int argc;

7  char *argv[];

8  {

9   register int result, ix;

10  extern int factorial(), atoi();

11

12  DBUG_ENTER("main");

13  DBUG_PROCESS(argv[0]);

14  DBUG_PUSH_ENV("DBUG");

15  for (ix = 1; ix < argc && argv[ix][0] == '-'; ix++) {

16   switch (argv[ix][1]) {

17   case '#':

18    DBUG_PUSH(&(argv[ix][2]));

19    break;

20   }

21  }

22  for (; ix < argc; ix++) {

23   DBUG_PRINT("args", ("argv[%d] = %s", ix, argv[ix]));

24   result = factorial(atoi(argv(ixj));

25   printf("%d\n", result);

26   fflush(stdout);

27  }

28  DBUG_RETURN(0);

29 }

Эта программа иллюстрирует большинство важных моментов. Макрос DBUG_ENTER() (строка 12) должен быть вызван после объявлений переменных и перед любым другим кодом. (Это потому, что он сам объявляет несколько частных переменных.[176])

Макрос DBUG_PROCESS() (строка 13) устанавливает имя программы, главным образом, для использования в выводимых библиотекой сообщениях. Этот макрос должен вызываться лишь однажды, из main().

Макрос DBUG_PUSH_ENV() (строка 14) заставляет библиотеку проверить указанную переменную окружения (в данном случае DBUG) на предмет управляющей строки (Управляющие строки dbug вскоре будут рассмотрены.) Библиотека может, сохранив свое текущее состояние и использовав новое, создавать стек сохраненных состояний. Таким образом, этот макрос помещает в стек сохраненных состояний полученное от данной переменной окружения состояние. В данном примере использован случай, когда макрос создает первоначальное состояние. Если такой переменной окружения нет, ничего не происходит. (В качестве отступления, DBUG является довольно общей переменной, возможно, GAWK_DBUG было бы лучше [для gawk].)

Макрос DBUG_PUSH (строка 18) передает значение управляющей строки, полученной из опции командной строки -#. (Новый код должен использовать getopt() или getopt_long() вместо ручного анализа аргументов.) Таким образом обычно включается режим отладки, но использование переменной окружения предоставляет также дополнительную гибкость.

Макрос DBUG_PRINT() (строка 23) осуществляет вывод. Второй аргумент использует методику, которую мы описали ранее (см. раздел 15.4.1.1 «Используйте отладочные макросы»), по включению в скобки всего списка аргументов printf(), делая его простым аргументом,насколько это касается препроцессора С. Обратите внимание, что завершающий символ конца строки в форматирующей строке не указывается; библиотека dbug вставляет его за вас.

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

Наконец, макрос DBUG_RETURN() (строка 28) используется вместо обычного оператора return для возврата значения. Для использования с функциями void имеется соответствующий макрос DBUG_VOID_RETURN.

Оставшаяся часть программы заполнена функцией factorial():

1  #include <stdio.h>

2  #include "dbug.h"

3

4  int factorial (value)

5  register int value;

6  {

7   DBUG_ENTER("factorial");

8   DBUG_PRINT("find", ("find %d factorial", value));

9   if (value > 1) {

10   value *= factorial(value — 1);

11  }

12  DBUG_PRINT("result", ("result is %d", value));

13  DBUG_RETURN(value);

14 }

Когда программа откомпилирована и скомпонована вместе с библиотекой dbug, ее можно запустить обычным способом. По умолчанию, программа не создает вывод отладки. Но со включенной отладкой доступны различные виды вывода:

$ factorial 1 2 3 /* Обычный запуск, без отладки */

1

2

6

$ factorial -#t 1 2 3/* Вывести трассировку вызовов функций, обратите внимание на вложенность */

| >factorial

| <factorial

1 /* Обычный вывод в stdout */

| >factorial

| | >factorial

| | <factorial /* Вывод отладки в stderr */

| <factorial

2

| >factorial

| | >factorial

| | | >factorial

| | | <factorial

| | <factorial

| <factorial

6

<?func?

$ factorial -#d 1 2/* Показать отладочные сообщения DBUG_PRINT() */

?func?: args: argv[2] = 1

factorial: find: find 1 factorial

factorial: result: result is 1

1

?func?: args: argv[3] = 2

factorial: find: find 2 factorial

factorial: find: find 1 factorial

factorial: result: result is 1

factorial: result: result is 2

2

Опция -# управляет библиотекой dbug. Она «особая» в том смысле, что DBUG_PUSH() будет принимать всю строку, игнорируя ведущие символы '-#', хотя вы могли бы использовать при желании другую опцию, передав DBUG_PUSH() лишь строку аргументов опций (если вы используете getopt(), это optarg).

Управляющая строка состоит из набора опций и аргументов. Каждая группа опций и аргументов отделяется от других символом двоеточия. Каждая опция представлена одной буквой, а аргументы этой опции отделяются от нее запятыми. Например:

$ myprog -#d,mem,ipc:f,check_salary,check_start_date -f infile -o outfile

Опция d включает вывод DBUG_PRINT(), но лишь если первая строка аргумента является "mem" или "ipc". (Если аргументов нет, выводятся все сообщения DBUG_PRINT().) Сходным образом опция f ограничивает трассировку вызовов функций лишь указанными функциями, check_salary() и check_start_date().

Следующий список опций и аргументов воспроизведен из руководства библиотеки dbug. Квадратные скобки заключают необязательные аргументы. Мы включаем здесь лишь те, которые находим полезными; полный список см. в документации.

d [,ключевые слова]

Разрешает вывод от макросов с указанными ключевыми словами. Пустой список ключевых слов предполагает, что выбраны все ключевые слова.

F

Помечает каждую строку вывода отладки именем исходного файла, содержащего макрос, осуществляющий вывод.

i

Идентифицирует процесс, выводящий каждую отладочную или трассировочную строку номером ID для этого процесса.

L

Помечает каждую строку вывода отладчика номером строки исходного файла, в котором находится осуществляющий вывод макрос.

о[,файл]

Перенаправляет поток вывода отладчика в указанный файл. Потоком вывода по умолчанию является stderr. Пустой список аргументов перенаправляет вывод в stdout.

t[,N]

Включает трассировку потока управления функций. Максимальная глубина вложения определяется N, по умолчанию используется 200.

Для завершения нашего обсуждения вот остальные макросы, определенные библиотекой dbug.

DBUG_EXECUTE(строка, код)

Этот макрос похож на DBUG_PRINT(): первый аргумент является строкой, выбранной с помощью опции d, а второй — код для исполнения:

DBUG_EXECUTE("abort", abort());

DBUG_FILE

Это значение типа FILE* для использования с процедурами <stdio.h>. Оно позволяет осуществлять собственный вывод в поток файла отладки.

DBUG_LONGJMP(jmp_buf env, int val)

Этот макрос заключает в оболочку вызов longjmp(), принимая те же самые аргументы, так что библиотека dbug будет знать, когда вы сделали нелокальный переход.

DBUG_POP()

Этот макрос выталкивает из стека один уровень сохраненного состояния отладки, созданный макросом DBUG_PUSH(). Он довольно эзотерический; вы скорее всего не будете его использовать.

DBUG_SETJMP(jmp_buf env)

Этот макрос заключает в оболочку вызов setjmp(), принимая те же самые аргументы. Он позволяет библиотеке dbug обрабатывать нелокальные переходы.

В другом воплощении, в первой начинающей компании, для которой мы работали[177], мы использовали в своем продукте библиотеку dbug. Она была неоценимой при разработке, а опустив -DDBUG в конечной сборке, мы смогли построить готовую версию без других изменений исходного кода.

Чтобы извлечь максимальную выгоду от библиотеки dbug, нужно использовать ее последовательно, по всей программе. Это проще, если вы используете ее с начала проекта, но в качестве эксперимента мы обнаружили, что с помощью простого сценария awk мы смогли включить библиотеку в программу с 30 000 строк кода за несколько часов работы. Если вы можете позволить себе накладные расходы, лучше всего оставить ее в конечной сборке вашей программы, чтобы можно было ее отлаживать без необходимости предварительной перекомпиляции.

Мы нашли, что библиотека dbug является удачным дополнением к внешним отладчикам, таким, как GDB; она обеспечивает организованный и последовательный способ применения поддержки к коду С. Она также довольно элегантно сочетает многие из методик, которые мы ранее в данной главе очертили отдельно. Особенно полезна особенность динамической трассировки вызовов функций, и она доказывает свою бесценность в качестве помощи в изучении поведения программы, если вы незнакомы с ней.

15.5.2. Отладчики выделения памяти

Игнорируя такие проблемы, как плохой дизайн программы, для любого крупномасштабного практического приложения единственной сложной задачей программиста на С является управление динамической памятью (посредством malloc(), realloc() и free()).

Этот факт подкреплен большим количеством инструментов, доступных для отладки динамической памяти. Имеется значительное перекрывание того, что предлагают данные утилиты. Например:

• Обнаружение утечек памяти: память, которая выделяется, а затем становится недоступной.

• Обнаружение не освобождаемой памяти: память, которая выделяется, но никогда не освобождается. Не освобождаемая память не всегда является ошибкой, но определение таких случаев дает вам возможность проверить, что с ними все в порядке.

• Обнаружение неправильных освобождений: память, которая освобождается дважды, или функции free() передаются указатели, которые не были получены с помощью malloc().

• Обнаружение использования уже освобожденной памяти: память, которая освобождена, используется через висячий указатель.

• Обнаружение выхода за границы выделенной памяти: получение доступа или сохранение в память за пределами выделенной границы.

• Предупреждение об использовании неинициализированной памяти. (Многие компиляторы могут выдавать такие предупреждения.)

• Динамическая трассировка функций: когда появляется ошибочный доступ к памяти, вы получаете трассировку от того места, где память используется, до того места, где она была выделена.

• Управление инструментами посредством использования переменных окружения.

• Файлы журналов для необработанной отладочной информации, которая может быть обработана позже для создания полезных отчетов.

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

Некоторые инструменты требуют изменения исходного кода, такого, как вызов специальных функций или использование особого заголовочного файла, дополнительных #define и статической библиотеки. Другие работают посредством использования специального механизма библиотек общего пользования Linux/Unix для прозрачной установки себя в качестве заместителя стандартных библиотечных версий malloc() и free().

В данном разделе мы рассмотрим три отладчика динамической памяти, а затем предоставим ссылки на несколько других.

15.5.2.1. GNU/Linux mtrace

Системы GNU/Linux, использующие GLIBC, предоставляют две функции для включения и отключения трассировки памяти во время исполнения.

#include <mcheck.h> /* GLIBC */


void mtrace(void);

void muntrace(void);

Когда вызывается mtrace(), библиотека проверяет переменную окружения MALLOC_TRACE. Ожидается, что она указывает на записываемый файл (существующий или нет). Библиотека открывает файл и начинает записывать сведения о выделениях и освобождениях памяти (Если файл не может быть открыт, запись не производится. Файл урезается каждый раз при запуске программы.) Когда вызывается muntrace(), библиотека закрывает файл и больше не регистрирует выделения и освобождения.

Использование отдельных функций дает возможность проводить трассировку памяти для определенных частей программы; необязательно отслеживать все. (Мы нашли наиболее полезным включить журналирование в начале программы и все, но эта схема предоставляет гибкость, которую хорошо иметь.)

Когда приложение завершается, вы используете программу mtrace для анализа файла журнала. (Файл журнала в формате ASCII, но информацию нельзя использовать непосредственно.) Например, gawk включает трассировку, если определена TIDYMEM:

$ export TIDYMEM=1 MALLOC_TRACE=trace.out /* Экспортировать переменные окружения */

$ ./gawk 'BEGIN { print "hello, world" }' /* Запустить программу */

hello, world

$ mtrace ./gawk mtrace.out /* Создать отчет */

Memory not freed:

-----------------

Address Size Caller

0x08085858 0x20  at /home/arnold/Gnu/gawk/gawk-3.1.3/main.c:1102

0x08085880 0xc80 at /home/arnold/Gnu/gawk/gawk-3.1.3/node.c:398

0x08086508 0x2   at /home/arnold/Gnu/gawk/gawk-3.1.3/node.c:337

0x08086518 0x6   at /home/arnold/Gnu/gawk/gawk-3.1.3/node.c:337

0x08086528 0x10  at /home/arnold/Gnu/gawk/gawk-3.1.3/eval.c:2082

0x08086550 0x3   at /home/arnold/Gnu/gawk/gawk-3.1.3/node.с:337

0x08086560 0x3   at /home/arnold/Gnu/gawk/gawk-3.1.3/node.c:337

0x080865e0 0x4   at /home/arnold/Gnu/gawk/gawk-3.1.3/field.c:76

0x08086670 0x78  at /home/arnold/Gnu/gawk/gawk-3.1.3/awkgram.y:1369

0x08086700 0xe   at /home/arnold/Gnu/gawk/gawk-3.1.3/node.c:337

0x08086718 0x1f  at /home/arnold/Gnu/gawk/gawk-3.1.3/awkgram.y:1259

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

15.5.2.2. Electric Fence

В разделе 3.1 «Адресное пространство Linux/Unix» мы описали, как динамическая память выделяется из кучи, которая может расти и сокращаться (с помощью вызовов brk() или sbrk(), описанных в разделе 3.2.3 «Системные вызовы: brk() и sbrk()»).

Ну, картина, которую мы там представили, является упрощением действительности. Более развитые системные вызовы (не рассматриваемые в данной книге) позволяют добавлять в адресное пространство процесса дополнительные, необязательно смежные сегменты памяти. Многие отладчики malloc() работают с использованием этих системных вызовов для добавления новых областей адресного пространства при каждом выделении. Преимуществом этой схемы является то, что операционная система и аппаратное обеспечение защиты памяти компьютера взаимодействуют для обеспечения недействительности доступа к памяти за пределами этих изолированных сегментов, генерируя сигнал SIGSEGV. Эта схема изображена на рис. 15.1.

Рис. 15.1. Адресное пространство Linux/Unix, включая специальные области

Первым пакетом отладки, реализовавшим эту схему, был Electric Fence. Electric Fence является вставляемым заместителем для malloc() и др. Он работает на многих системах Unix и GNU/Linux; он доступен с FTP архива его авторов.[178] Он поставляется также со многими дистрибутивами GNU/Linux, хотя, возможно, вам придется выбрать ею явным образом при установке системы.

После компоновки программы с Electric Fence любой доступ за пределами выделенной памяти генерирует SIGSEGV. Electric Fence также перехватывает попытки использования уже освобожденной памяти. Вот простая программа, которая иллюстрирует обе проблемы.

1  /* ch15-badmem1.с --- плохо обращается с памятью */

2

3  #include <stdio.h>

4  #include <stdlib.h>

5

6  int main(int argc, char **argv)

7  {

8   char *p;

9   int i;

10

11  p = malloc(30);

12

13  strcpy(p, "not 30 bytes");

14  printf("p = <%s>\n", p);

15

16  if (argc ==2) {

17   if (strcmp(argv[1], "-b") == 0)

18    p[42] = 'a'; /* коснуться за пределами границы */

19   else if (strcmp(argv[1], "-f") == 0) {

20    free(p); /* освободить память, затем использовать ее */

21    p[0] = 'b';

22   }

23  }

24

25  /* освобождение (p); */

26

27  return 0;

28 }

Эта программа осуществляет простую проверку опций командной строки, чтобы решить, как вести себя плохо: -b вызывает доступ к памяти за ее выделенными страницами, а -f пытается использовать освобожденную память. (Строки 18 и 21 являются соответственно опасными.) Обратите внимание, что без опций указатель никогда не освобождается (строка 25), Electric Fence не перехватывает этот случай.

Одним из способов использования Electric Fence, способом, который гарантированно работает на различных системах Unix и GNU/Linux, является статическая компоновка с ним вашей программы. Затем программа должна быть запущена из отладчика. (Документация Electric Fence явно указывает, что Electric Fence не следует компоновать с двоичным файлом готового изделия.) Следующий сеанс демонстрирует эту процедуру и показывает, что происходит для обеих опций командной строки:

$ cc -g ch15-badmem1.c -lefence -о ch15-badmem1 /* Откомпилировать; компоновка статическая */

$ gdb ch15-badmem1 /* Запустить из отладчика */

GNU gdb 5.3

...

(gdb) run -b /* Попробовать опцию -b */

Starting program: /home/arnold/progex/code/ch15/ch15-badmem1 -b

[New Thread 8192 (LWP 28021)]

Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>

p = <not 30 bytes>

Program received signal SIGSBGV, Segmentation fault.

SIGSBGV: GDB prints where

[Switching to Thread 8192 (LWP 28021)]

0x080485b6 in main (argc=2, argv=0xbffff8a4) at ch15-badmem1.c:18

18 p[42] = 'a'; /* коснуться за пределами границы */

(gdb) run -f /* Теперь попробовать опцию -f */

The program being debugged has been started already.

Start it from the beginning? (y or n) y /* Да */

Starting program: /home/arnold/progex/code/ch15/ch15-badmem1 -f

[New Thread 8192 (LWP 28024)]

Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com>

p = <not 30 bytes>

Program received signal SIGSEGV, Segmentation fault. /* Снова SIGSEGV */

[Switching to Thread 8192 (LWP 28024)]

0x080485e8 in main (argc=2, argv=0xbffff8a4) at ch15-badmem1.c:21

21 p[0] = 'b';

На системах, которые поддерживают разделяемые библиотеки и переменную окружения LD_PRELOAD (в том числе и на GNU/Linux), вам не нужно явным образом компоновать библиотеку efence. Вместо этого сценарий оболочки ef организует запуск программы с соответствующей настройкой.

Хотя мы не описали механизмы подробно, GNU/Linux (и другие системы Unix) поддерживают разделяемые (shared) библиотеки, особые версии библиотечных процедур, которые хранятся в одном файле на диске, вместо того, чтобы копироваться в каждый отдельный двоичный исполняемый файл программы. Разделяемые библиотеки экономят дисковое пространство и могут сохранить системную память, поскольку все программы, использующие разделяемые библиотеки, используют одну и ту же копию библиотеки в памяти. Платой за это является замедление загрузки программы, поскольку программу и разделяемую библиотеку нужно подключить друг к другу прежде, чем программа сможет начать выполнение. (Обычно это прозрачно для вас, пользователя.)

Переменная окружения LD_PRELOAD заставляет системный загрузчик программ (который загружает исполняемые файлы в память) связаться со специальной библиотекой до стандартных библиотек. Сценарий ef использует эту особенность для связывания набора функций malloc() в Electric Fence.[179] Таким образом, повторная компоновка даже не нужна. Этот пример демонстрирует ef:

$ cc -g ch15-badmem1.c -о ch15-badmem1 /* Компилировать как обычно */

$ ef ch15-badmem1 -b /* Запустить с использованием ef, создает дамп ядра */


Electric Fence 2.2.0 Copyright (С) 1987-1999 Bruce Perens <bruce@perens.com>

p = <not 30 bytes>

/usr/bin/ef: line 20: 28005 Segmentation fault (core dumped)

( export LD_PRELOAD=libefence.so.0.0; exec $* )

$ ef ch15-badmem1 -f /* Запустить с использованием ef, снова создает дамп ядра */

Electric Fence 2.2.0 Copyright (С) 1987-1999 Bruce Perens <bruce@perens.com>

p = <not 30 bytes>

/usr/bin/ef: line 20: 28007 Segmentation fault (core dumped)

( export LD_PRELOAD=libefence.so.0.0; exec $* )

$ ls -l core* /* Linux создает для нас разные файлы core */

-rw------- 1 arnold devel 217088 Aug 28 15:40 core.28005

-rw------- 1 arnold devel 212992 Aug 28 15:40 core.28007

GNU/Linux создает файлы core, которые включают в свое имя ID процесса. В данном случае такое поведение полезно, поскольку мы можем отдельно отлаживать каждый файл core:

$ gdb ch15-badmem1 core.28005 /* От опции -b */

GNU gdb 5.3

...

Core was generated by 'ch15-badmem1 -b'.

Program terminated with signal 11, Segmentation fault.

...

#0 0x08048466 in main (argc=2, argv=0xbffff8c4) at ch15-badmem1.c:18

18 p[42] = 'a'; /* touch outside the bounds */

(gdb) quit


$ gdb ch15-badmem1 core.28007 /* От опции -f */

GNU gdb 5.3

...

Core was generated by 'ch15-badmem1 -f'.

Program terminated with signal 11, Segmentation fault.

...

#0 0x08048498 in main (argc=2, argv=0xbffff8c4) at ch15-badmem1.с:21

21 p[0] = 'b';

Справочная страница efence(3) описывает несколько переменных окружения, которые должны быть установлены, чтобы настроить поведение Electric Fence. Следующие три наиболее примечательны.

EF_PROTECT_BELOW

Установка этой переменной в 1 заставляет Electric Fence проверять «недоборы» (underruns) вместо «переборов» (overruns) при выходе за пределы отведенной памяти. «Перебор», т.е. доступ к памяти в области за выделенной, был продемонстрирован ранее. «Недобор» является доступом к памяти, расположенной перед выделенной областью памяти.

EF_PROTECT_FREE

Установка этой переменной в 1 предотвращает повторное использование Electric Fence памяти, которая была корректно освобождена. Это полезно, когда вы думаете, что программа может получать доступ к освобожденной памяти; если освобожденная память впоследствии была выделена заново, доступ к ней через предыдущий висячий указатель остался бы в противном случае незамеченным.

EF_ALLOW_MALLOC_0

При наличии ненулевого значения Electric Fence допускает вызовы 'malloc(0)'. Такие вызовы в стандартном С технически действительны, но могут представлять программную ошибку. Соответственно Electric Fence по умолчанию их запрещает.

Вдобавок к переменным окружения Electric Fence предоставляет глобальные переменные с такими же названиями. Вы можете изменить их значения из отладчика, так что можно динамически изменять поведение программы, которая уже начала выполнение. Подробности см. в efence(3).

15.5.2.3. Отладка Malloc: dmalloc

Библиотека dmalloc предоставляет большое число опций отладки. Ее автором является Грей Ватсон (Gray Watson), есть также и свой веб-сайт.[180] Как и в случае с Electric Fence, она может быть уже установленной на вашей системе, или же вы можете ее извлечь и построить самостоятельно.

Библиотека dmalloc проверяет наличие в переменной окружения DMALLOC_OPTIONS управляющей информации. Например, она может выглядеть следующим образом:

$ echo $DMALLOC_OPTIONS

debug=0x4e40503,inter=100,log=dm-log

Компонент 'debug' этой переменной содержит набор битовых флагов, которыми для большинства людей почти невозможно непосредственно управлять. Поэтому документация описывает двухэтапный процесс для облегчения их использования.

Первый шаг заключается в определении функции оболочки с названием dmalloc, которая вызывает программу драйвера dmalloc:

$ dmalloc() {

> eval 'command dmalloc -b $*' /* Команда 'command' обходит функции оболочки */

> }

После того, как это сделано, вы можете передать функции опции для установки файла журнала (-1), указать число итераций, после которых dmalloc должна проверить свои внутренние структуры данных (-1), и указать уровень отладки или другой тэг ('low').

$ dmalloc -1 dm-log -i 100 low

Как и Electric Fence, библиотека dmalloc может быть скомпонована с приложением статически или связана динамически при помощи LD_PRELOAD. Последнее демонстрирует следующий пример:

$ LD_PRELOAD=libdmalloc.so ch15-badmem1 -b /* Запустить с проверкой */

p = <not 30 bytes> /* Показан нормальный вывод */

ЗАМЕЧАНИЕ. Не используйте 'export LD_PRELOAD=libdmalloc.so'! Если вы это сделаете, каждая программа, которую вы запустите, такая как ls, будет выполняться со включенной проверкой malloc(). Ваша система быстро станет непригодной. Если вы сделали это случайно, можете использовать 'unset LD_PRELOAD', чтобы восстановить обычное поведение.

Результаты записываются в файл dm-log следующим образом:

$ cat dm-log

1062078174: 1: Dmalloc version '4.8.1' from 'http://dmalloc.com/'

1062078174: 1: flags = 0x4e40503, logfile 'dm-log'

1062078174: 1: interval = 100, addr = 0, seen # = 0

1062078174: 1: starting time = 1062078174

1062078174: 1: free bucket count/bits: 63/6

1062078174: 1: basic-block 4096 bytes, alignment 8 bytes, heap grows up

1062078174: 1: heap: 0x804a000 to 0x804d000, size 12288 bytes (3 blocks)

1062078174: 1: heap checked 0

1062078174: 1: alloc calls: malloc 1, calloc 0, realloc 0, free 0

1062078174: 1: alloc calls: recalloc 0, memalign 0, valloc 0

1062078174: 1: total memory allocated: 30 bytes (1 pnts)

1062078174: 1: max in use at one time: 30 bytes (1 pnts)

1062078174: 1: max alloced with 1 call: 30 bytes

1062078174: 1: max alloc rounding loss: 34 bytes (53%)

1062078174: 1: max memory space wasted: 3998 bytes (98%)

1062078174: 1: final user memory space: basic 0, divided 1, 4062 bytes

1062078174: 1: final admin overhead: basic 1, divided 1, 8192 bytes (66%)

1062078174: 1: final external space: 0 bytes (0 blocks)

1062078174: 1: top 10 allocations:

1062078174: 1: total-size count in-use-size count source

1062078174: 1:         30     1          30     1 ra=0x8048412

1062078174: 1:         30     1          30     1 Total of 1

1062078174: 1: dumping not-freed pointers changed since 0:

1062078174: 1: not freed: '0x804c008|s1' (30 bytes) from 'ra=0x8048412'

1062078174: 1: total-size count source

1062078174: 1:         30     1 ra=0x8048412 /* Выделение здесь */

1062078174: 1:         30     1 Total of 1

1062078174: 1: unknown memory: 1 pointer, 30 bytes

1062078174: 1: ending time = 1062078174, elapsed since start = 0:00:00

Вывод содержит много статистических данных, которые нам пока не интересны. Интересна строка, в которой указывается не освобожденная память, с адресом возврата, указывающим на выделившую память функцию ('ra=0х8048412'). Документация dmalloc объясняет, как получить расположение в исходном коде этого адреса с использованием GDB.

$ gdb ch15-badmem1 /* Запустить GDB */

GNU gdb 5.3

...

(gdb) x 0x8048412 /* Проверить адрес */

0x8048412 <main+26>: 0х8910с483

(gdb) info line *(0x8048412) /* Получить сведения о строке */

Line 11 of "ch15-badmem1.с" starts at address 0x8048408 <main+16>

and ends at 0x8048418 <main+32>.

Это трудно, но выполнимо, если нет другого выбора. Однако, если вы включите в свою программу заголовочный файл "dmalloc.h" (после всех остальных операторов #include), вы можете получить сведения из исходного кода непосредственно в отчете.

...

1062080258: 1: top 10 allocations:

1062080258: 1: total-size count in-use-size count source

1062080258: 1:        30      1          30     1 ch15-badmem2.c:13

1062080258: 1:        30      1          30     1 Total of 1

1062080258: 1: dumping not-freed pointers changed since 0:

1062080258: 1: not freed: '0x804c008|s1' (30 bytes) from 'ch15-badmem2.c:13'

1062080258: 1: total-size count source

1062080258: 1:         30     1 ch15-badmem2.с:13

1062080258: 1:         30     1 Total of 1

...

(Файл ch15-badmem2.c является аналогичным ch15-badmem1.с, за исключением того, что он включает "dmalloc.h", поэтому мы не стали беспокоиться с его отображением).

Отдельные возможности отладки включаются или выключаются посредством использования лексем (tokens) — специально распознаваемых идентификаторов — и опций для добавления лексем (свойств) или -m для их удаления. Имеются предопределенные комбинации, 'low', 'med' и 'high'. Чем являются эти комбинации, вы можете увидеть с помощью 'dmalloc -Lv'.

$ dmalloc low /* Установить low */

$ dmalloc -Lv /* Показать установки */

Debug Malloc Utility: http://dmalloc.com/

For a list of the command-line options enter: dmalloc --usage

Debug-Flags 0x4e40503 (82052355) (low) /* Текущие лексемы */

log-stats, log-non-free, log-bad-space, log-elapsed-time, check-fence,

free-blank, error-abort, alloc-blank, catch-null

Address not-set

Interval 100

Lock-On not-set

Logpath 'log2'

Start-File not-set

Полный список лексем вместе с кратким объяснением и соответствующим каждой лексеме числовым значением можно получить с помощью 'dmalloc -DV':

$ dmalloc -DV

Debug Tokens:

none (nil) -- no functionality (0)

log-stats (lst) -- log general statistics (0x1)

log-non-free (lnf) -- log non-freed pointers (0x2)

log-known (lkn) -- log only known non-freed (0x4)

log-trans (ltr) -- log memory transactions (0x8)

log-admin (lad) -- log administrative info (0x20)

log-blocks (lbl) -- log blocks when heap-map (0x40)

log-bad-space (lbs) -- dump space from bad pnt (0x100)

log-nonfree-space (lns) -- dump space from non-freed pointers (0x200)

log-elapsed-time (let) -- log elapsed-time for allocated pointer (0x40000)

log-current-time (let) -- log current-time for allocated pointer (0x80000)

check-fence (cfe) -- check fence-post errors (0x400)

check-heap (che) -- check heap adm structs (0x800)

check-lists (cli) -- check free lists (0x1000)

check-blank (cbl) -- check mem overwritten by alloc-blank, free-blank (0x2000)

check-funcs (cfu) -- check functions (0x4000)

force-linear (fli) -- force heap space to be linear (0x10000)

catch-signals (csi) -- shutdown program on SIGHUP, SIGINT, SIGTERM (0x20000)

realloc-copy (rco) -- copy all re-allocations (0x100000)

free-blank (fbl) -- overwrite freed memory space with BLANK_CHAR (0x200000)

error-abort (eab) -- abort immediately on error (0x400000)

alloc-blank (abl) -- overwrite newly alloced memory with BLANK_CHAR (0x800000)

heap-check-map (hem) -- log heap-map on heap-check (0x1000000)

print-messages (pme) -- write messages to stderr (0x2000000)

catch-null (cnu) -- abort if no memory available (0x4000000)

never-reuse (nre) -- never re-use freed memory (0x8000000)

allow-free-null (afn) -- allow the frees of NULL pointers (0x20000000)

error-dump (edu) -- dump core on error and then continue (0x40000000)

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

15.5.2.4. Valgrind: многосторонний инструмент

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

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

Valgrind является гибким инструментом для отладки и профилирования исполняемых файлов Linux-x86. Инструмент состоит из ядра, которое программно обеспечивает искусственный процессор x86, и ряда «оболочек», каждая из которых является отладочным или профилирующим инструментом. Архитектура модульная, так что можно легко создавать новые «оболочки», не нарушая существующую структуру.

Наиболее полезной «оболочкой» является memcheck.

«Оболочка» memcheck обнаруживает в ваших программах проблемы с управлением памятью. Проверяются все чтения и записи памяти, а вызовы malloc/new/free/delete перехватываются. В результате memcheck может обнаружить следующие проблемы

• Использование неинициализированной памяти.

• Чтение/запись в память после ее освобождения.

• Чтение/запись за границей выделенного malloc блока.

• Чтение/запись в ненадлежащие области стека.

• Утечки памяти, когда указатели на выделенные malloc теряются навсегда.

• Несоответствующее использование malloc/new/new[] против free/delete/delete[].

• Некоторые неправильные употребления pthreads API POSIX.

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

Другие «оболочки» более специализированы:

• cachegrind осуществляет обстоятельную имитацию кэшей I1, D1 и L2 процессора, поэтому может точно указать источники осечек кэшей в вашем коде.

• addrcheck идентична memcheck за исключением одной детали — она не проверяет неинициализированные данные. Все остальные проверки — главным образом, точная проверка адресов — по-прежнему проводится. Обратной стороной этого является то, что вы не перехватываете ошибки неинициализированных данных, которые может найти memcheck.

Но положительная сторона значительна: программы работают почти в два раза быстрее, чем с memcheck, используя значительно меньше памяти. Утилита по-прежнему находит чтения/записи освобожденной памяти, памяти за пределами выделенных блоков и в других недействительных местах, ошибки, которые вы действительно хотите обнаружить до выпуска программы в свет!

• helgrind является отладочной оболочкой, предназначенной для обнаружения состязания данных в многопоточных программах.

Наконец, руководство отмечает:

Valgrind тесно связан с особенностями процессора, операционной системы и, в меньшей степени, компилятора и основных библиотек С. Это затрудняет его переносимость, поэтому мы с самого начала сконцентрировались на том, что мы считаем широко использующейся платформой: Linux на x86. Valgrind использует стандартный механизм Unix './configure', 'make', 'make install', и мы попытались обеспечить его работу на машинах с ядром 2.2 или 2.4 и glibc 2.1.X, 2.2.X или 2.3.1. Это должно охватить значительное большинство современных установок Linux. Обратите внимание, что glibc-2.3.2+ с пакетом NPTL (Native POSIX Thread Library — собственная библиотека потоков POSIX) не будет работать. Мы надеемся исправить это, но это будет нелегко.

Если вы используете GNU/Linux на другой платформе или используете коммерческую систему Unix, Valgrind не окажет вам большой помощи. Однако, поскольку системы GNU/Linux на x86 довольно обычны (и вполне доступны), вполне вероятно, что вы сможете приобрести ее с умеренным бюджетом, или по крайней мере, занять на время! Что еще, когда Valgrind нашел для вас проблему, она исправляется для любой платформы, для которой компилируется ваша программа. Таким образом, разумно использовать систему x86 GNU/Linux для разработки, а какую-нибудь другую коммерческую систему Unix для развертывания высококачественного продукта.[181]

Хотя из руководства Valgrind у вас могло сложиться впечатление, что существуют отдельные команды memcheck, addrcheck и т.д., это не так. Вместо этого программа оболочки драйвера с именем valgrind запускает отладочное ядро с соответствующей «оболочкой», указанной в опции --skin=. Оболочкой по умолчанию является memcheck; таким образом, запуск просто valgrind равносильно 'valgrind --skin=memcheck' (Это обеспечивает совместимость с более ранними версиями Valgrind, которые осуществляли лишь проверку памяти, это имеет также больший смысл, поскольку оболочка memcheck предоставляет большую часть сведений.)

Valgrind предусматривает ряд опций. За всеми подробностями мы отсылаем вас к его документации. Опции поделены на две группы; из тех, которые используются с ядром (т. е. работают для всех оболочек), наиболее полезными могут быть следующие:

--gdb-attach=no/yes

Запускается с подключенным к процессу GDB для интерактивной отладки. По умолчанию используется no.

--help

Перечисляет опции.

--logfile=файл

Записывает сообщения в файл.pid.

--num-callers=число

Выводит число вызывающих в трассировке стека. По умолчанию 4.

--skin=оболочка

Использует соответствующую оболочку. По умолчанию memcheck.

--trace-children=no|yes

Запускает трассировку также в порожденных процессах. По умолчанию используется no.

-V, --verbose

Использует более полный вывод. Это включает перечисление загруженных библиотек, а также подсчеты всех различных видов ошибок.

Из опций для оболочки memcheck мы полагаем, что эти являются наиболее полезными.

--leak-check=no|yes

Искать утечки памяти после завершения программы. По умолчанию используется no.

--show-reachable=no|yes

Показать доступные блоки после завершения программы. Если используется --show-reachable=yes, Valgrind ищет динамически выделенную память, на которую все еще есть указывающий на нее указатель. Такая память не является утечкой, но о ней все равно следует знать. По умолчанию используется no.

Давайте посмотрим на Valgrind в действии. Помните ch15-badmem.c? (См. раздел 15.5.2.2 «Electric Fence».) Опция -b записывает в память, находящуюся вне выделенного malloc() блока. Вот что сообщает Valgrind:

$ valgrind ch15-badmem1 -b

1  ==8716== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.

2  ==8716== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.

3  ==8716== Using valgrind-20030725, a program supervision framework for x86-linux.

4  ==8716== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.

5  ==8716== Estimated CPU clock rate is 2400 MHz

6  ==8716== For more details, rerun with: -v

7  ==8716==

8  p = <not 30 bytes>

9  ==8716== Invalid write of size 1

10 ==8716== at 0x8048466: main (ch15-badmem1.c:18)

11 ==8716== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

12 ==8716== by 0x8048368: (within /home/arnold/progex/code/ch15/ch15-badmem1)

13 ==8716== Address 0x4104804E is 12 bytes after a block of size 30 alloc'd

14 ==8716== at 0x40025488: malloc (vg_replace_malloc.с:153)

15 ==8716== by 0x8048411: main (ch15-badmem1.c:11)

16 ==8716== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

17 ==8716== by 0x8048368: (within /home/arnold/progex/code/ch15/ch15-badmem1)

18 ==8716==

19 ==8716== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

20 ==8716== malloc/free: in use at exit: 30 bytes in 1 blocks.

21 ==8716== malloc/free: 1 allocs, 0 frees, 30 bytes allocated.

22 ==8716== For a detailed leak analysis, rerun with: --leak-check=yes

23 ==8716== For counts of detected errors, rerun with: -v

(Были добавлены номера строк в выводе, чтобы облегчить обсуждение.) Строка 8 является выводом программы; остальные от Valgrind в стандартную ошибку. Сообщение об ошибке находится в строках 9–17. Она указывает, сколько байтов было записано неверно (строка 9), где это случилось (строка 10), и показывает трассировку стека. Строки 13–17 описывают, откуда была выделена память. Строки 19–23 подводят итоги.

Опция -f программы ch15-badmem1 освобождает выделенную память, а затем записывает в нее через висячий указатель. Вот что сообщает Valgrind в этом случае:

$ valgrind ch15-badmem1 -f

==8719== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.

...

p = <not 30 bytes>

==8719== Invalid write of size 1

==8719== at 0x8048498: main (ch15-badmem1.с:21)

==8719== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

==8719== by 0x8048368: (within /home/arnold/progex/code/ch15/ch15-badmem1)

==8719== Address 0x41048024 is 0 bytes inside a block of size 30 free'd

==8719== at 0x40025722: free (vg_replace_malloc.с:220)

==8719== by 0x8048491: main (ch15-badmem1.c:20)

==8719== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

==8719== by 0x8048368: (within /home/arnold/progex/code/ch15/ch15-badmem1)

...

На этот раз в отчете указано, что запись была осуществлена в освобожденную память и что вызов free() находится в строке 20 ch15-badmem1.c.

При вызове без опций ch15-badmem1.c выделяет и использует память, но не освобождает ее. О таком случае сообщает опция —leak-check=yes:

$ valgrind --leak-check=yes ch15-badmem1

1  ==8720== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.

...

8  p = <not 30 bytes>

9  ==8720==

10 ==8720== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

11 ==8720== malloc/free: in use at exit: 30 bytes in 1 blocks.

12 ==8720== malloc/free: 1 allocs, 0 frees, 30 bytes allocated.

...

16 ==8720==

17 ==8720== 30 bytes in 1 blocks are definitely lost in loss record 1 of 1

18 ==8720== at 0x40025488: malloc (vg_replace_malloc.c:153)

19 ==8720== by 0x8048411: main (ch15-badmem1.c:11)

20 ==8720== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

21 ==8720== by 0x8048368: (within /home/arnold/progex/code/ch15/ch15-badmem1)

22 ==8720==

23 ==8720== LEAK SUMMARY:

24 ==8720== definitely lost: 30 bytes in 1 blocks.

25 ==8720== possibly lost: 0 bytes in 0 blocks.

26 ==8720== still reachable: 0 bytes in 0 blocks.

27 ==8720== suppressed: 0 bytes in 0 blocks.

28 ==8720== Reachable blocks (those to which a pointer was found) are not shown.

29 ==8720== To see them, rerun with: --show-reachable=yes

Строки 17–29 предоставляют отчет об утечке; эта память была выделена в строке 11 ch15-badmem1.с.

Помимо отчетов о неправильном использовании динамической памяти, Valgrind может диагностировать использование неинициализированной памяти. Рассмотрим следующую программу, ch15-badmem3.c:

1  /* ch15-badmem3.c --- плохое обращение с нединамической памятью */

2

3  #include <stdio.h>

4  #include <stdlib.h>

5

6  int main(int argc, char **argv)

7  {

8   int a_var; /* Обе не инициализированы */

9   int b_var;

10

11  /* Valgrind не отметит это; см. текст. */

12  a_var = b_var;

13

14  /* Использование неинициализированной памяти; это отмечается. */

15  printf("a_var = %d\n", a_var);

16

17  return 0;

18 }

При запуске Valgrind выдает этот (сокращенный) отчет:

==29650== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.

...

==29650== Use of uninitialised value of size 4

==29650== at 0x42049D2A: _IO_vfprintf_internal (in /lib/i686/libc-2.2.93.so)

==29650== by 0x420523C1: _IO_printf (in /lib/1686/libc-2.2.93.so)

==29650== by 0x804834D: main (ch15-badmem3.с:15)

==29650== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

==29650==

==29650== Conditional jump or move depends on uninitialised value(s)

==29650== at 0X42049D32: _IO_vfprintf_internal (in /lib/i686/libc-2.2.93.so)

==29650== by 0x420523C1: _IO_printf (in / lib/i686/libc-2.2.93.so)

==29650== by 0x804834D: main (ch15-badmem3.c:15)

==29650== by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)

...

a_var = 1107341000

==29650==

==29650== ERROR SUMMARY: 25 errors from 7 contexts (suppressed: 0 from 0)

==29650== malloc/free: in use at exit: 0 bytes in 0 blocks.

==29650== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.

==29650== For a detailed leak analysis, rerun with: --leak-check=yes

==29650== For counts of detected errors, rerun with: -v

В документации Valgrind объясняется, что копирование неинициализированных данных не выдает сообщений об ошибках. Оболочка memcheck отмечает состояние данных (неинициализированные) и отслеживает его при перемещениях данных. Таким образом, a_var считается неинициализированной, поскольку это значение было получено от b_var, которая была неинициализированной.

memcheck сообщает о проблеме лишь тогда, когда неинициализированное значение используется. Здесь это происходит в библиотеке С (_IO_vfprintf_internal()), которая должна преобразовать значение в строку, для этого, она проводит с этим значением вычисления.

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

В заключение, Valgrind является мощным инструментом отладки памяти. Он использовался в таких крупномасштабных, многопоточных производственных программах, как KDE 3, OpenOffice и веб-браузер Konqueror. Он конкурирует с несколькими коммерческими предложениями, а другая его версия была даже использована (совместно с эмулятором WINE[182]) для отладки программ, написанных для Microsoft Windows с использованием Visual С++! Вы можете получить Valgrind с его веб-сайта[183].

15.5.2.5. Другие отладчики malloc

Две статьи Cal Ericson в Linux Journal описывают mtrace и dmalloc, а также большинство других перечисленных ниже инструментов. Эти статьи Memory Leak Detection in Embedded Systems, выпуск 101[184], сентябрь 2002 г., и Memory Leak Detection in C++, выпуск 110[185], июнь 2003 г. Обе статьи доступны на веб-сайте Linux Journal.

Другие инструменты сходны по природе с описанными ранее.

ccmalloc

Замещающая malloc() библиотека, которая не нуждается в особой компиляции и можетиспользоваться с С++. См. http://www.inf.ethz.ch/personal/biere/projects/ccmalloc.

malloc Марка Мораеса (Mark Moraes)

Старинная, но полнофункциональная библиотека замещения malloc(), предоставляющая возможности профилирования, трассировки и отладки. Вы можете получить ее с ftp://ftp.cs.toronto.edu/pub/moraes/malloc-1.18.tar.gz.

mpatrol

Пакет с большими возможностями настройки для отладки памяти и тестирования. См http://www.cbmamiga.demon.со.uk/mpatrol.

memwatch

Пакет, требующий использования специального заголовочного файла и опций времени компилирования. См. http://www.linkdata.se/sourcecode.html.

njamd

«Не просто еще один отладчик malloc» (Not Just Another Malloc Debugger). Эта библиотека не требует специальной компоновки с приложением; вместо этого она использует LD_PRELOAD для замены стандартных процедур. См. http://sourceforge.net/projects/njamd.

yamd

Похож на Electric Fence, но со многими дополнительными опциями. См. http://www3.hmc.edu/~neldredge/yamd.

Почти все из этих пакетов используют для точной настройки своего поведения переменные окружения. В таблице 15.1 на основе статей из Linux Journal сделана сводка различных пакетов.


Таблица 15.1. Сводка особенностей инструментов памяти

Инструмент ОС Заголовочный файл Модуль/ программа Многопоточность
ccmalloc Многотипная Нет Программа Нет
dmalloc Многотипная Необязательно Программа Да
efence Многотипная Нет Программа Нет
memwatch Многотипная Да Программа Нет
Moraes Многотипная Необязательно Программа Нет
mpatrol Многотипная Нет Программа Да
mtrace Linux (GLIBC) Да Модуль Нет
njamd Многотипная Нет Программа Нет
valgrind Linux (GLIBC) Нет Программа Да
yamd Linux, DJGPP Нет Программа Нет
Как видно, для отладки проблем динамической памяти доступен ряд выборов. На системах GNU/Linux и BSD один или более из этих инструментов, возможно, уже установлены, что избавляет вас от хлопот по их загрузке и построению.

Полезно также использовать для своей программы несколько инструментов подряд. Например, mtrace для обнаружения не освобождаемой памяти, a Electric Fence для перехвата доступа к недействительной памяти.

15.5.3. Современная lint

В оригинальном С компилятор не мог проверить, соответствуют ли параметры, переданные в вызове функции, списку параметров в определении функции; прототипов не было. Это часто вело к неуловимым ошибкам, поскольку ошибочный вызов функции мог вызывать лишь частично ошибочные результаты, которые проходили незамеченными во время тестирования, или мог даже вообще не появиться во время тестирования. Например:

if (argc < 2)

 fprintf ("usage: %s [ options ] files\n", argv[0]);

  /* отсутствует stderr */

Если программа, содержащая этот фрагмент, никогда не вызывается с ошибочным числом аргументов, fprintf(), в которой отсутствует первый аргумент FILE*, также никогда не вызывается.

Программа V7 lint была предназначена для решения таких проблем. Она делала два прохода через все файлы программы, сначала собирая сведения об аргументах функций, а затем сравнивая вызовы функций с собранной информацией. Особые файлы «библиотеки lint» предоставляли сведения о функциях стандартных библиотек, так что их также можно было проверить, lint проверяла также другие сомнительные конструкции.

С появлением в стандартном С прототипов необходимость в lint уменьшилась, но не исчезла совсем, поскольку C89 все еще допускает объявления функций в старом стиле.

extern int some_func(); /* Список аргументов неизвестен */

Вдобавок, многие другие аспекты программы можно проверять статически, т.е. путем анализа исходных текстов.

Программа splint (Secure Programming Lint — Lint для безопасного программирования)[186] является современным обновлением lint. Она предусматривает слишком много опций и возможностей, чтобы перечислять их здесь, но ее стоит исследовать.

Следует знать об одной особенности подобных lint программ, которая заключается в том, что они выводят целый поток предупреждающих сообщений. Многие из сообщаемых предупреждений в действительности безвредны. В таких случаях инструменты допускают использование специальных комментариев, сообщающих. «Да, я знаю об этом, это не проблема», splint лучше всего работает, когда вы предоставляете в своем коде большое количество подобных примечаний.

splint является мощным, но сложным инструментом; выделение некоторого времени на изучение его использования, а затем частое его использование поможет сохранить ваш код ясным.

15.6. Тестирование программ

Разработка программного обеспечения содержит элементы и искусства, и науки, это одна сторона того, что делает ее такой восхищающей и стимулирующей профессией. Данный раздел вводит в тему тестирования программного обеспечения, которая также включает в себя и искусство, и науку; таким образом, это несколько более общий и высокий уровень (читай: «на который можно махнуть рукой»), чем остальная часть данной главы.

Тестирование программ является неотъемлемой частью процесса разработки программного обеспечения. Весьма маловероятно, что программа заработает правильно на 100 процентов при первой компиляции. Программа не несет ответственности за свою правильность; за это отвечает автор программы. Одним из самых важных способов проверки того, что программа работает так, как предполагалось, является ее тестирование.

Один из способов классификации различных видов тестов следующий:

Тесты модулей (Unit tests)

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

Важно спроектировать тесты для каждого функционального компонента во время его разработки. Это помогает прояснить проектирование особенностей; знание того, как это тестировать, помогает определить, что следует и что не следует делать в первую очередь.

Комплексные тесты (Integration tests)

Это тесты, которые применяются, когда все функциональные компоненты были написаны, протестированы и отлажены по отдельности. Идея в том, что все затем помешается на свое место в каркасе и тестируется все в целом, чтобы убедиться, что взаимодействия между компонентами работают.

Возвратные тесты (Regression tests)

Неизбежно вы (или ваши пользователи!) обнаружат проблемы. Это могут быть действительные ошибки, или ограничения дизайна, или неизбежные отказы в «пограничных случаях». Когда вы смогли воспроизвести и исправить проблему, сохраните первоначальные условия отказа в качестве возвратного теста.

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

Тестирование следует по возможности автоматизировать. Это особенно легко сделать для программ, не содержащих графического пользовательского интерфейса (GUI), написанных в стиле инструментов Linux/Unix: читающих стандартный ввод или указанные файлы и записывающих в стандартный вывод и стандартную ошибку. По меньшей мере, тестирование можно осуществить с помощью простых сценариев оболочки. Более сложное тестирование осуществляется обычно с помощью отдельного подкаталога test и программы make.

Тестирование программного обеспечения само по себе является отдельной областью, и мы не предполагаем отдавать ей здесь должное; скорее, наше намерение дать вам знание, что тестирование является неотъемлемой частью разработки и часто движущей силой для использования ваших навыков в отладке! Вот очень короткий резюмирующий список.

• Проектируйте тест вместе с функциональностью

• Тестируйте пограничные условия: убедитесь, что функция работает внутри и на действительных границах и что она корректно выдает ошибку за их пределами. (Например, функция sqrt() должна потерпеть неудачу с отрицательным аргументом).

• Используйте в своем коде операторы проверки (см. раздел 12.1 «Операторы проверки assert()») и проведите свои тесты с разрешенными операторами проверки.

• Создайте и используйте повторно тестовое окружение.

• Сохраняйте условия сбоев для возвратного тестирования

• Как можно больше автоматизируйте тестирование.

• Печатайте число потерпевших неудачу тестов, чтобы легко можно было определить успех или неудачу, а также степень неудачи.

• Используйте инструменты обзора кода, такие, как gcov, чтобы удостовериться, что ваш набор тестов охватывает весь ваш код.

• Тестируйте с самого начала и тестируйте часто.

• Изучите литературу по тестированию программного обеспечения, чтобы совершенствовать свою способность разрабатывать и тестировать программное обеспечение.

15.7. Правила отладки

Отладка не является «черной магией». Ее принципы и методики могут быть изучены и последовательно применены каждым. С этой целью мы рекомендуем книгу Debugging Дэвида Эганса (David J. Agans; ISBN: 0-8144-7168-4). У книги есть веб-сайт[187], на котором обобщены правила и представлен плакат для загрузки, чтобы вы могли его распечатать и повесить на стену в своем офисе.

Чтобы завершить наше обсуждение, мы представляем следующий материал. Он был адаптирован Дэвидом Эгансом по разрешению из Debugging, Copyright © 2002 David J. Agans, опубликованной AMACOM[188], отделением American Management Association, New York. Мы благодарим его.

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

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

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

Если ошибка все еще непостоянна, вам придется сделать так, чтобы она выглядела постоянной. При каждом запуске фиксируйте в журнале каждый бит информации, какой только сможете; затем, когда есть успешные запуски и сбои, сравните их друг с другом. Если вы собрали достаточно данных, вы сможете нацелиться на проблему, как если бы смогли вызывать ошибку все время. Способность вызывать каждый раз ошибку означает также, что вы сможете сказать, когда вы ее исправили.

3. Прекратите думать и смотрите. Имеется больше способов появления ошибок, чем вы можете себе представить. Поэтому не представляйте, что могло бы случиться, смотрите на это — оснастите систему инструментарием, чтобы вы действительно смогли увидеть механизм ошибки. Используйте любой инструментарий, который можете — отладчики, printf(), assert(), анализаторы логики и даже светодиоды и звуковые сигнализаторы. Проверяйте достаточно глубоко, пока ошибка не станет очевидной для глаз, а не только для мозга.

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

4. Разделяй и властвуй. Каждый это знает. Вы делаете последовательное приближение — начинаете с одного конца, перескакиваете полпути, смотрите, с какой стороны ошибка, затем перескакиваете оставшиеся полпути в направлении ошибки. Бинарный поиск, вы оказываетесь так за несколько прыжков. Трудной частью является определение того, прошли вы ошибку или нет. Одной из полезных уловок является помещение в систему известных, простых данных, так чтобы можно было легче узнать мусор. Начните также с плохого конца и работайте по направлению к хорошему: если вы начнете с хорошего конца, имеется слишком много хороших путей для исследования. Известные ошибки исправляйте сразу, поскольку иногда две ошибки взаимодействуют (хотя вы могли бы поклясться, что они не должны этого делать), и последовательное приближение не работает с двумя целевыми значениями.

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

Если вы делаете изменение, а результата не видно, немедленно вернитесь обратно. Возможно, оно имело результат, который вы не увидели, и он может проявиться в сочетании с другими изменениями. Это относится к изменениям как в тестировании, так и в кодировании.

6. Сохраняйте контрольные журналы. Многое в эффективности приведенных выше правил зависит от сохранения хороших записей. Во всех отношениях тестирования и отладки записывайте, что вы делали, когда вы это делали, как вы это делали и что случилось в результате. По возможности делайте это в электронном виде, чтобы записи можно было послать по электронной почте и прикрепить к базе данных ошибок. Многие ключи можно найти в паттернах событий, которые были бы не замечены, если бы все они не записывались для просмотра и сравнения. Ключ может находиться также в деталях, о которых вы думали, что они неважны, поэтому запишите их все.

7. Проверьте подключение. У каждого есть история о какой-нибудь проблеме, оказавшейся в том, что «это не было подключено». Иногда что-то оказывается буквально не подключенным, но для программного обеспечения «не подключено» может означать отсутствующий драйвер или старую версию кода, о которой вы думали, что заменили ее. Или плохое оборудование, когда вы клянетесь, что это проблема программного обеспечения. В одной истории инженеры-программисты и электронщики показывали пальцами друг на друга, и никто не был прав: тестирующее устройство, которое они использовали, не соответствовало спецификации. Основной момент в том, что иногда вы ищете проблему внутри системы, тогда как на самом деле она вне системы, или лежит в основе системы, или в инициализации системы, или вы смотрите не на ту систему.

Не следует также непременно доверять своим инструментам. Производители инструментов также являются инженерами; у них есть ошибки, и вы можете оказаться тем, кто их обнаружит.

8. Оцените свежим взглядом. Есть три причины попросить помощи при отладке.

Первая причина в получении свежего взгляда — другие люди часто видят что-то лишь потому, что они не вовлечены в это так, как вы. Вторая причина заключается в получении экспертной оценки — они знают о системе больше, чем вы. Третья причина заключается в получении опыта — они видели это раньше.

Когда вы описываете ситуацию кому-либо, сообщите о симптомах, которые вы видели, а не о своих предположениях, почему это происходит так. Вы пришли к ним, потому что ваши предположения не ведут вас никуда — не тяните их в ту же колею, в которую попали сами.

9. Если вы не исправили это, это не исправлено. Так вы думаете, это исправлено? Испытайте. Раз вы могли заставить ошибку повторяться постоянно, создайте ту же самую ситуацию и убедитесь, что ошибки нет. Не думайте, что все исправлено лишь потому, что проблема была очевидной. Может, она не была такой очевидной. Может, ваше исправление не было сделано правильно. Может, ваше исправление даже не находится в новом выпуске! Проверьте! Заставьте ошибку исчезнуть.

Вы уверены, что именно ваш код исправил проблему? Или это произошло из-за изменения теста, или туда был внесен какой-то другой код? Когда вы видите, что ваше исправление работает, уберите его и заставьте ошибку появиться снова. Затем верните исправление на место и убедитесь, что ошибки нет. Этот шаг гарантирует, что именно ваше исправление решило проблему.

Дополнительные сведения о книге Debugging и плакат с правилами отладки можно найти для свободной загрузки по адресу http://www.debuggingrules.com.

15.8. Рекомендуемая литература

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

1. Debugging, David J. Agans. AMACOM, New York, New York. USA 2003. ISBN: 0-8144-7168-4.

Настоятельно рекомендуем эту книгу. У нее легкий стиль, удивительное звучание, чтение — одно удовольствие!

2. Programming Pearls, 2nd edition, by Jon Louis Bentley. Addison-Wesley, Reading, Massachusetts, USA, 2000, ISBN: 0-201-63788-0. См. также веб-сайт этой книги.[189]

В главе 5 этой книги приведено хорошее обсуждение тестирования элементов и построения тестовой среды.

3. Literate Programming, by Donald E. Knuth. Center for the Study of Language and Information (CSLI), Stanford University, USA, 1992. ISBN: 0-9370-7380-6.

Эта восхитительная книга содержит ряд статей Дональда Кнута по грамотному программированию (literate programming) — методике программирования, которую он изобрел и использовал для создания ТеХ и Metafont. Особый интерес представляет статья, озаглавленная «Ошибки ТеХ», которая описывает, как он разрабатывал и отлаживал ТеХ, включая его журнал всех найденных и исправленных ошибок.

4. Writing Solid Code, by Steve Maguire. Microsoft Press, Redmond, Washington, USA, 1993. ISBN 1-55615-551-4.

5. Code Complete: A Practical Handbook of Software Construction, by Steve McConnell Microsoft Press, Redmond, Washington, USA, 1994. ISBN: 1-55615-484-4.

6. The Practice of Programming, by Brian W. Kernighan and Rob Pike. Addison-Wesley, Reading. Massachusetts, USA, 1999. ISBN: 0-201-61585-X.

15.9. Резюме

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

• Программы должны компилироваться без оптимизации и с включенными идентификаторами отладки, чтобы упростить отладку под отладчиком. На многих системах компиляция с оптимизацией и компиляция с идентификаторами отладки несовместимы. Это не относится к GCC, вот почему разработчикам GNU/Linux нужно знать об этой проблеме.

• Отладчик GNU GDB является стандартом на системах GNU/Linux и может использоваться также почти на любой коммерческой системе Unix. (Также доступны и легко переносимы графические отладчики на основе GDB.) Контрольные точки, отслеживаемые точки и пошаговое исполнение с посредством next, step и cont предоставляют базовый контроль над программой при ее работе. GDB позволяет также проверять данные и вызывать функции внутри отлаживаемой программы.

 • Имеется множество вещей, которые вы можете сделать при написании программы для ее упрощения, когда неизбежно придется ее отлаживать. Мы рассмотрели следующие темы:

 • Отладочные макросы для вывода состояния.

 • Избегание макросов с выражениями.

 • Перестановку кода для облегчения пошагового выполнения.

 • Написание вспомогательных функций для использования их из отладчика.

 • Избегание объединений.

 • Помещение отладочного кода времени исполнения в готовую версию программы и обеспечение различных способов включения вывода этого кода.

 • Добавление фиктивных функций для упрощения установки контрольных точек.

• Для помощи при отладке помимо простых отладчиков общего назначения существует ряд инструментов и библиотек. Библиотека dbug предоставляет элегантный внутренний отладчик, который использует многие из описанных нами методик последовательным, связанным образом.

• Существует множество отладочных библиотек для динамической памяти, имеющие сходные свойства. Мы рассмотрели три из них (mtrace, Electric Fence и dmalloc) и предоставили ссылки на несколько других. Программа Valgrind идет еще дальше, обнаруживая проблемы, относящиеся к неинициализированной памяти, а не только к динамической памяти.

• splint является современной альтернативой многоуважаемой программе V7 lint. Она доступна по крайней мере на системе одного из поставщиков GNU/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?

 • Решите, как будут работать кавычки: одинарные и двойные? Или лишь одна разновидность? Как вы поместите в кавычки сами кавычки? Как кавычки будут взаимодействовать с перенаправлениями ввода/вывода?

 • Как вы обработаете вызов команд в фоновом режиме? Что насчет ожидания завершения работы команды в фоновом режиме?

 • Решите, будут ли у вас переменные оболочки.

 • Какую разновидность символов подстановки или других расширений будете вы поддерживать? Как это взаимодействует с кавычками? С переменными оболочки?

 • Вы должны запланировать по крайней мере операторы if и while. Спроектируйте синтаксис. Мы будем называть их блочными операторами.

 • Решите, хотите ли вы разрешить перенаправления ввода/вывода для блочных операторов. Если да, как будет выглядеть синтаксис?

 • Решите, как язык вашей оболочки должен обрабатывать сигналы, если он вообще это делает.

 • Разработайте шаблон тестирования и отладки до того, как вы начнете программировать.

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

3. Для настоящей работы начните просто. Начальная версия должна читать одну строку за раз и разделять ее на слова для использования в качестве отдельных аргументов. Не используйте кавычек, перенаправления ввода-вывода или что-нибудь еще. Не старайтесь даже создать новый процесс для запуска введенной программы. Как вы собираетесь тестировать то, что у вас пока есть?

4. Добавьте кавычки так, чтобы отдельные «слова» могли содержать разделители. Реализует ли код для кавычек ваш проект?

5. Заставьте работать ваши встроенные команды. (По крайней мере две нужные встроенные команды см. в разделах 4.6 «Создание файлов» и 8.4.1 «Смена каталога: chdir() и fchdir()».) Как вы собираетесь их тестировать?

6. Первоначально используйте фиксированный путь поиска, такой как "/bin:/usr/bin:/usr/local/bin". Добавьте создание процесса при помощи fork() и его исполнение при помощи exec(). (См. главу 9 «Управление процессами и каналы».) Запустив новую программу, оболочка должна ждать ее завершения.

7. Добавьте фоновое исполнение и, в качестве отдельной команды, ожидание завершения выполнения процесса (см. главу 9 «Управление процессами и каналы»).

8. Добавьте устанавливаемый пользователем путь поиска (см. раздел 2.4 «Переменные окружения»).

9. Добавьте перенаправление ввода/вывода для файлов (см. раздел 9.4 «Управление дескрипторами файлов»).

10. Добавьте переменные оболочки. Протестируйте их взаимодействие с кавычками.

11. Добавьте символы подстановки и другие расширения (см. раздел 12.7 «Расширения метасимволов»). Протестируйте их взаимодействие с переменными оболочки. Протестируйте их взаимодействие с кавычками.

12. Добавьте конвейеры (см. раздел 9.3 «Базовое межпроцессное взаимодействие: каналы и очереди FIFO»). С этого момента начинаются настоящие сложности. Вам может потребоваться тщательно рассмотреть то, как вы управляете данными, представляющими запускаемые команды.

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

13. Если вы принимаете дальнейший вызов, добавьте операторы if и/или while.

14. Добавьте обработку сигналов (см. главу 10 «Сигналы»).

15. Если вы хотели бы использовать свою оболочку для настоящей работы, изучите библиотеку GNU Readline (наберите в системе GNU/Linux 'info readline' или посмотрите исходный код для оболочки Bash). Эта библиотека дает вам возможность добавлять к интерактивным программам возможность редактирования командной строки в стиле Emacs или vi.

Постоянно держите в уме две вещи- всегда имейте возможность протестировать то, что вы делаете; и «никаких произвольных ограничений»!

Когда все это сделано, проделайте анализ сделанного проекта. Как вы сделали бы его по-другому во второй раз? Удачи!

16.2. Рекомендуемая литература

1. The UNIX Programming Environment, by Brian W. Kernighan and Rob Pike. Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1984. ISBN: 0-13-937699-2.[190]

Эта классическая книга по программированию на Unix, описывающая целостную структуру окружения Unix, от интерактивного использования до программирования оболочки, программирования с помощью функций <stdio.h> и низкоуровневых системных вызовов, разработки программ с помощью make, yacc и lex, и документирования с помощью nroff и troff.

Хотя возраст книги приличный, ее в высшей степени стоит прочесть, и мы ее чрезвычайно рекомендуем.

2. The Art of UNIX Programming, by Eric S. Raymond. Addison-Wesley, Reading, Massachusetts, USA, 2004. ISBN: 0-13-142901-9.

Это книга на более высоком уровне фокусируется на проблемах проектирования при программировании в Unix: как работают программы Unix и как разрабатывать свои собственные программы, чтобы уютно вписаться в окружение Linux/Unix. Хотя мы не всегда согласны со многим из того, что хочет сказать автор, книга действительно содержит значительное количество важного материала, и ее стоит прочесть.

Часть 4 Приложения

Приложение А Научитесь программированию за десять лет

«Опыт, сущ.: Нечто, что вы не получаете до тех пор, пока это вам не понадобится».

- Оливер -
Данная глава написана Петером Норвигом (Peter Norvig, © 2001 г.). Воспроизводится по разрешению. Оригинальную статью, включая гиперссылки, можно найти по адресу http://www.norvig.com/21-days.html. Мы включили ее, поскольку полагаем, что она содержит важную идею. Приведенная цитата является одной из наших давних любимых, и поскольку она применима к сути нашего приложения, мы ее также включили.

Почему каждый в такой спешке?

Зайдите в любой книжный магазин, и вы увидите «Научитесь Java за 7 дней» наряду с бесконечными вариациями, предлагающими научиться Visual Basic, Windows, Internet и т.д. за несколько дней или часов. Я произвел следующий расширенный поиск на Amazon.com:

pubdate: after 1992 and title: days and

(title: learn or title: teach yourself)

и получил 248 попаданий. Первые 78 были компьютерными книгами (номер 79 был «Изучите Бенгали за 30 дней»). Я заменил «дни» ('days') на «часы» ('hours') и получил замечательным образом сходные результаты: еще 253 книг, из них 77 компьютерных, за которыми следовала под номером 78 «Научитесь грамматике и стилистике за 24 часа». Всего из верхних 200 книг 96% были компьютерные.

Вывод таков, что либо люди очень торопятся изучить компьютеры, либо эти компьютеры каким-то образом фантастически легче изучить, чем что-то еще. Книг о том, как изучить Бетховена, или квантовую физику, или даже научиться ухаживать за собакой за несколько дней, нет.

Давайте проанализируем, что может означать название наподобие «Изучите Паскаль за три дня»:

• Изучите: за 3 дня у вас не будет времени написать несколько значительных программ и научиться из них на своих успехах и неудачах. У вас не будет времени поработать с опытным программистом и понять, на что похожа жизнь в этом окружении. Короче, у вас не будет времени научиться многому. Поэтому можно говорить лишь о поверхностном знакомстве, а не глубоком понимании. Как сказал римский папа Александр, неглубокое знание является опасной вещью.

• Паскаль: за 3 дня вы смогли бы изучить синтаксис Паскаля (если вы уже знаете сходный язык), но не смогли бы много узнать о том, как использовать этот синтаксис. Короче, если бы вы были программистом на Бейсике, вы смогли бы писать программы в стиле Бейсика на Паскале, но не смогли бы изучить, для чего Паскаль в действительности подходит (или не подходит). В чем же суть? Алан Перлис (Alan Perlis) сказал однажды: «Язык, который не влияет на способ вашего мышления о программировании, не стоит того, чтобы его знали». Другими словами, вам приходится изучить крошечный кусок Паскаля (или, более вероятно, чего-то наподобие Visual Basic или JavaScript), поскольку вам нужно взаимодействовать с существующим инструментом для выполнения определенной задачи. Но тогда вы не обучаетесь программированию; вы учитесь выполнять эту задачу.

• За три дня: к сожалению, этого недостаточно, как показывает следующий раздел.

Научитесь программированию за десять лет

Ученые (Hayes, Bloom) показали, что развитие высокой квалификации в любой из широкого разнообразия областей, включая шахматы, сочинение музыки, рисование, игра на фортепьяно, плавание, теннис, исследования в нейропсихологии и топологии, занимают около десяти лет. По-видимому, в действительности не может быть сокращения: даже Моцарту, который был музыкально одаренным уже в 4 года, потребовалось еще 13 лет, прежде чем он начал создавать мировую классическую музыку. В другом жанре Битлз, казалось, вырвались на сцену, появившись в шоу Эда Салливана в 1964 г. Но они играли с 1957 года, и хотя они рано завоевали широкую популярность, их первый переломный успех, Сержант Пепперс, был выпущен в 1967 г. Сэмюэл Джонсон (Samuel Johnson) считал, что требуется более десяти лет: «Мастерство в любой отрасли достигается лишь работой в течение жизни; его нельзя купить по меньшей цене». А Чосер (Chaucer) жаловался: «Жизнь так коротка, а ремеслу так долго учиться».

Вот мой рецепт для успеха в программировании:

• Заинтересуйтесь программированием и сделайте что-нибудь, потому что это забавно. Убедитесь, что оно продолжает оставаться достаточно интересным, чтобы вы хотели прилагать усилия в течение десяти лет.

• Говорите с другими программистами; читайте другие программы. Это важнее, чем любая книга или учебный курс.

• Программируйте. Лучшей разновидностью обучения является обучение деланием. Говоря более технически, «максимальный уровень производительности индивидуума в данной области не достигается автоматически как функция расширения опыта, но его могут повысить даже очень опытные индивидуумы в результате обдуманных усилий по совершенствованию» и «наиболее эффективное обучение требует хорошо определенной задачи с соответствующим уровнем трудности для данного конкретного индивидуума, информационной обратной связи и возможностей повторения и исправления ошибок». Книга Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life (Практическое познание мышление, математика и совершенствование способностей в повседневной жизни) является интересным справочным пособием для этой точки зрения.

• Если хотите, проведите четыре года в колледже (или еще больше в аспирантуре). Это даст вам доступ к некоторым видам работ, требующим диплома, и это даст более глубокое понимание области, но если вам не нравится школа, вы можете (с некоторым упорством) получить аналогичный опыт на работе В любом случае, одного лишь изучения книг недостаточно. «Образование в компьютерных науках может сделать кого-нибудь искусным программистом не в большей степени, чем изучение кистей и красок может сделать кого-то искусным художником», — говорит Эрик Реймонд (Eric Raymond), автор The New Hacker's Dictionary (Словаря новых хакеров). Один из лучших программистов, которых я когда-либо принимал на работу, имел лишь среднее образование, он создал массу превосходных программ, у него есть своя группа новостей и через фондовые опционы, без сомнения, намного богаче, чем буду я когда-либо.

• Работайте над проектами с другими программистами. Будьте лучшим программистом в некоторых проектах; будьте худшим в некоторых других. Когда вы лучший, вы принимаетесь проверять свои способности возглавлять проект и вдохновлять других своим видением. Когда вы худший, вы изучаете то, что делают мастера, и вы изучаете, что они не любят делать (поскольку они заставляют делать это за себя вас).

• Работайте над проектами после других программистов. Погрузитесь в понимание программы, написанной кем-то еще. Посмотрите, чего стоит понять и исправить ее, когда рядом нет авторов программы. Подумайте над тем, как спроектировать свои программы, чтобы сделать их проще для тех, кто будет их сопровождать после вас.

• Изучите по крайней мере полдюжины языков программирования. Включите один язык, поддерживающий абстракции классов (подобно Java или С++), один, поддерживающий функциональные абстракции (подобно Lisp или ML), один, поддерживающий синтаксические абстракции (подобно Lisp), один, поддерживающий декларативные спецификации (подобно Prolog или шаблонам C++), один, поддерживающий сопрограммы (подобно Icon или Scheme), и одни, поддерживающий параллелизм (подобно Sisal).

• Помните, что в «компьютерных науках» есть «компьютер». Знайте, сколько времени ваш компьютер тратит на исполнение инструкции, получение слова из памяти (с попаданием в кэш и без попадания), чтение последовательных слов с диска и поиск нового положения на диске (Ответы ниже.)

• Погрузитесь в работу по стандартизации языка. Это может быть комитет ANSI С++, или это может быть принятием решения, должен ли ваш местный стиль программирования использовать 2 или 4 пробела в отступах. В любом случае, вы узнаете, что любят в языке другие люди, насколько глубоко они это чувствуют и, возможно, даже немного о том, почему они это чувствуют.

• Имейте здравый смысл, чтобы отделаться от работы по стандартизации языка как можно скорее.

Держа все это в уме, сомнительно, насколько далеко вы сможете уйти, обучаясь лишь по книгам. До рождения моего первого ребенка я прочел все книги How To (Как…), и до сих пор чувствую себя необразованным новичком. 30 месяцев спустя, когда ожидался мой второй ребенок, вернулся ли я к книгам, чтобы освежить их в памяти? Нет. Вместо этого я полагался на свой собственный опыт, который оказался для меня намного более полезным и обнадеживающим, чем тысячи страниц, написанных экспертами.

Фред Брукс (Fred Brooks) в своем эссе Никаких серебряных пуль (No Silver Bullets) определил план из трех частей для обнаружения великих проектировщиков программного обеспечения:

1. Систематически как можно раньше распознавать ведущих проектировщиков.

2. Назначить наставников по достижениям, ответственных за разработку перспективы и тщательно хранить архивы достижений.

3. Предоставлять растущим проектировщикам возможности для взаимодействия и стимулирования ими друг друга.

Это предполагает, что у некоторых людей уже есть качества, необходимые, чтобы стать великими проектировщиками; задача заключается в том, чтобы соответствующим образом их выманить. Алан Перлис (Alan Perlis) выразился более лаконично- «Каждого можно научить ваять: Микеланджело пришлось бы учить, как не делать это. Так же и с великими программистами».

Поэтому вперед, купите эту книгу по Java; возможно, вы получите от нее какую- нибудь пользу. Но вы не измените свою жизнь или свою действительную общую квалификацию как программиста за 24 часа, дня или даже месяцев.

Ссылки

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver, Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Ответы

Время выполнения различных операций на типичном ПК 1 ГГц летом 2001 г.:

исполнение одной инструкции  1 нс = (1/1000 000 000) сек

выборка слова из кэша L1  2 нс

выборка слова из основной памяти  10 нс

выборка смежного слова с диска  200 нс

выборка слова из нового места на диске (поиск) 8 000 000 нс = 8 мс

Сноски

Эта страница[191] доступна также в переводе на японский язык[192] благодаря Yasushi Murakawa и в переводе на испанский язык[193] благодаря Carlos Rueda.

T. Capey указывает, что страница Complete Problem Solver на Amazon теперь содержит книги Teach Yourself Bengali in 21 days и Teach Yourself Grammar and Style под рубрикой «Клиенты, которые купили эту книгу, купили также и эти книги». Я догадываюсь, что большая часть людей, посмотревших на ту книгу, пришли с этой страницы.

Приложение В Лицензия Caldera для старой Unix[194]

CALDERA

240 West Center Street

Orem, Utah 84057

801-765-4999 Fax 801-765-4481

23 января 2002 г.

Дорогие энтузиасты UNIX®,

Caldera International, Inc. настоящим предоставляет безвозмездную лицензию, которая включает права на использование, модификацию и распространение этого названного исходного кода, включая создание производных двоичных изделий из исходного кода. Исходный код, для которого Caldera International, Inc. передает права, ограничены следующими операционными системами UNIX, которые работают на 16-разрядном процессоре PDP-11 и ранних версиях 32-разрядной операционной системы UNIX, со специальным исключением UNIX System III и UNIX System V и операционных систем-наследников:

32-разрядной 32V UNIX,

16-разрядной UNIX версий 1, 2, 3, 4, 5, 6, 7.

Caldera International, Inc. не дает никаких гарантий или поручительств, что какой-нибудь исходный код доступен от Caldera International, Inc.

Следующее уведомление об авторских правах применяется к файлам исходного кода, для которых предоставляется данная лицензия.

Copyright © Caldera International Inc. 2001–2002. Все права сохранены. Разрешается распространение и использование в исходной и двоичной форме, с модификациями или без них, при соблюдении следующих условий:

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

Все рекламные материалы, упоминающие особенности или использование данного программного обеспечения, должны отображать следующее признание:

Этот продукт включает программное обеспечение, разработанное или принадлежащее Caldera International, Inc.

Ни название Caldera International, Inc., ни названия других внесших вклад участников не могут использоваться для поддержки или продвижения продуктов, производных отданного программного обеспечения, без особого предварительного письменного разрешения.

ИСПОЛЬЗОВАНИЕ ЭТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРЕДУСМОТРЕНО ПО ЛИЦЕНЗИИ CALDERA INTERNATIONAL, INC. И ДРУГИХ ВНЕСШИХ ВКЛАД УЧАСТНИКОВ «КАК ЕСТЬ» И БЕЗ ВСЯКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ НЕЯВНЫМИ ГАРАНТИЯМИ ПРИГОДНОСТИ ДЛЯ ПРОДАЖИ ИЛИ ПРИМЕНИМОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. НИ В КОЕМ СЛУЧАЕ CALDERA INTERNATIONAL, INC. НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ ПРЯМОЙ, КОСВЕННЫЙ, СЛУЧАЙНЫЙ, СПЕЦИАЛЬНЫЙ, ШТРАФНОЙ ИЛИ ЯВЛЯЮЩИЙСЯ СЛЕДСТВИЕМ УЩЕРБ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ПРИОБРЕТЕНИЕМ ИЛИ ЗАМЕНОЙ ТОВАРОВ; ПОТЕРЮ ЦЕННОСТИ, ДАННЫХ, УПУЩЕННУЮ ВЫГОДУ ИЛИ ПРИОСТАНОВКУ БИЗНЕСА), КАК БЫ ОН НИ БЫЛ ВЫЗВАН И В СООТВЕТСТВИИ С КАКИМИ БЫ ТО НИ БЫЛО ПРЕДПОЛОЖЕНИЯМИ, БУДЬ ТО В КОНТРАКТЕ, НЕПОСРЕДСТВЕННОЙ ОТВЕТСТВЕННОСТИ ИЛИ ГРАЖДАНСКОМ ПРАВОНАРУШЕНИИ (ВКЛЮЧАЯ НЕБРЕЖНОСТЬ ИЛИ ДРУГОЕ), ВОЗНИКШИЕ ЛЮБЫМ СПОСОБОМ ВСЛЕДСТВИЕ ИСПОЛЬЗОВАНИЯ ДАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ДАЖЕ В СЛУЧАЕ ПРЕДУПРЕЖДЕНИЯ О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА.

Искренне ваш,
(подпись) Bill Broderick
Bill Broderick
Директор, Служба лицензирования
UNIX является зарегистрированной торговой маркой Open Group в США и других странах.

Приложение С Общедоступная лицензия GNU[195]

Версия 2, июнь 1991 г.

Copyright © 1989, 1991 Free Software Foundation, Inc.

59 Temple Place, Suite 330, Boston, MA 02111, USA

Разрешается копировать и распространять дословные копии данного лицензионного документа, но не разрешается его изменять.

Преамбула
Лицензии большинства программных продуктов составлены так, чтобы отобрать у вас право совместно использовать и изменять продукт. По контрасту, Общедоступная лицензия GNU (GNU General Public License), напротив, подразумевает вашу свободу в совместном использовании и изменении свободного программного обеспечения — чтобы гарантировать, что программное обеспечение является свободным для всех своих пользователей. Данная Общедоступная лицензия применяется к большей части программного обеспечения Фонда независимых программ (Free Software Foundation) и к любой другой программе, авторы которой передают ее на использование с данной лицензией. (Некоторое другое программное обеспечение Фонду независимых программ защищается вместо этого Общедоступной библиотечной лицензией GNU (GNU Library General Public License).) Вы также можете использовать ее для своих программ.

Когда мы говорим о независимом программном обеспечении, мы имеем в виду свободу, а не цену. Наши Общедоступные лицензии разработаны так, чтобы гарантировать вам свободу распространять копии независимого программного обеспечения (и назначать за это цену, если хотите), получать исходный код, если хотите, изменять программное обеспечение или его части в новых независимых программах; а также гарантировать, что вы будете знать обо всех этих вещах.

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

Например, если вы распространяете копии таких программ, вне зависимости от того, бесплатно или за плату, вы обязаны дать получателям все права, которые есть у вас. Вы должны также обеспечить для них получение или возможность получения исходного кода. И вы должны довести до их сведения эти положения, чтобы они знали о своих правах.

Мы защищаем ваши права а два этапа: (1) обеспечивая авторское право на программное обеспечение и (2) предоставляя вам эту лицензию, которая дает вам законное разрешение копировать, распространять и/или модифицировать программное обеспечение.

Также, для защиты каждого автора и нашей собственной, мы хотим удостовериться в том, что каждый понимает, что на это независимое программное обеспечение нет гарантий. Если программное обеспечение модифицируется кем-либо еще и распространяется дальше, мы хотим, чтобы его получатели знали, что то, что они получают, не является оригиналом, поэтому любые проблемы, привнесенные другими, не должны отражаться на репутации автора оригинального продукта.

Наконец, любая независимая программа постоянно подвергается угрозе со стороны патентов на программное обеспечение. Мы хотим избежать опасности, когда распространители независимой программы получают отдельные патентные права, фактически превращая программу в патентованную. Чтобы предотвратить это, мы ясно дали понять, что любой патент должен предусматривать свободное его использование всеми или не регистрироваться вообще.

Далее следуют точные праве и обязанности при копировании, распространении и модификации.

Права и обязанности при копировании, распространении и модификации
0. Данная лицензия распространяется на любую программу или другой продукт, который содержит размещенное владельцем авторских прав уведомление, заявляющее, что этот продукт может распространяться в соответствии с условиями данной Общедоступной лицензии. Используемый далее термин «Программа» относится к любым таким программе или продукту, а «продукт, основанный на Программе» означает либо саму Программу, либо любой производный продукт, защищаемый законом об авторском праве: то есть продукт, содержащий Программу или часть ее, воспроизведенный точно или с модификациями и/или переведенный на другой язык. (В дальнейшем перевод без ограничений включается в термин «модификация».) К каждому обладателю лицензии обращение следует как «вы».

Другая деятельность, отличная от копирования, распространения и модификации, не охватывается данной Лицензией; она выходит за рамки ее действия. Акт запуска Программы на выполнение не ограничивается, а результаты работы Программы попадают под действие Лицензии лишь в том случае, если их содержание составляет продукт на основе Программы (независимо от того, было ли это сделано путем запуска Программы). Правомочность этого положения зависит от того, что делает Программа.

1. Вы можете копировать и распространять дословные копии исходного кода Программы в том виде, как вы его получили, с помощью любого средства при условии, что вы открыто и соответствующим образом опубликуете в каждой копни соответствующее заявление об авторских правах и отказе от гарантий; сохраните без изменений все заявления, ссылающиеся на данную Лицензию и на отсутствие каких-либо гарантий, и предоставите всем остальным получателям Программы вместе с самой Программой копию данной Лицензии.

Вы можете назначить плату за акт физического копирования, вы можете также по своему усмотрению предоставить гарантию на платной основе.

2. Вы вправе модифицировать свою копию или копии Программы или любую их часть, создавая тем самым продукт, основанный на Программе, и копировать и распространять такие модификации или продукты на условиях Параграфа 1, приведенного выше, при условии, что вы будете также следовать всем нижеприведенным требованиям:

 a. Модифицированные файлы должны иметь заметные предупреждения о том, что вы изменили файлы, с указанием даты изменений.

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

 c. Если модифицированная программа обычно интерактивно принимает команды при работе, вы должны обеспечить при ее запуске стандартным способом для такого интерактивного использования выведение на печать или отображение на экране сообщения, включающего соответствующее заявление об авторских правах и заявление об отсутствии гарантий (либо, в противном случае, заявляющее о предоставлении гарантии вами) и о том, что пользователи могут далее распространять программу на данных условиях, и сообщающее пользователю, как можно просмотреть копню данной Лицензии. (Исключение: если сама Программа интерактивная, но обычно не выводит подобного сообщения, от вашего продукта, основанного на Программе, не требуется выводить это сообщение).

Эти требования применяются к модифицированному продукту в целом. Если идентифицируемые разделы этого продукта не являются производными от Программы и могут с основанием рассматриваться независимыми и отдельными продуктами сами по себе, тогда данная лицензия и ее условия неприменимы к этим разделам при распространении их в качестве отдельных продуктов. Но когда вы распространяете те же разделы в виде целого, являющегося продуктом, основанным на Программе, распространение этого целого должно соответствовать положениям данной Лицензии, положения которой для обладателей лицензии распространяется на все целое и, таким образом, на каждую отдельную часть независимо от того, кто ее написал.

Таким образом, цель данного раздела состоит не в том, чтобы заявить свои права или оспорить ваши права на продукт, написанный исключительно вами; целью скорее является использование права контролировать распространение производных или совместных продуктов, основанных на Программе.

В дополнение, простое объединение другого продукта, не основанного на Программе, с Программой (или продуктом, основанным на Программе) на одном носителе информации или среде передачи данных не включает другой продукт в сферу применения данной Лицензии.

3. Вы вправе копировать и распространять Программу (или продукт, основанный на ней, в соответствии с Параграфом 2) в виде объектного кода или исполняемой программы, при выполнении условий, оговоренных в Параграфах 1 и 2, обеспечив также соблюдение одного из следующих требований:

 a. Сопроводив ее соответствующим полным исходным кодом в электронной форме, который должен распространяться в соответствии с вышеприведенными условиями Параграфов 1 и 2, на носителях, обычно используемых для обмена программами; или

 b. Сопроводив ее письменным предложением, действительным по крайней мере в течение трех лет, на предоставление любой третьей стороне по цене, не превышающей стоимость затрат на физическое распространение исходного кода, полной копии соответствующего исходного кода в электронном виде для распространения в соответствии с вышеприведенными условиями Параграфов 1 и 2, на носителях, обычно используемых для обмена программами; или

 c. Сопроводив ее сведениями, которые вы получили в качестве предложения распространения соответствующего исходного кода. (Данный вариант допустим лишь для некоммерческого распространения и лишь в том случае, если вы получили программу в виде объектного кода или исполняемого модуля с данным предложением, в соответствии с вышеприведенным Подпунктом b.)

Исходный код для продукта означает предпочтительную форму продукта для внесения изменений. Для продукта исполняемого модуля полный исходный код означает весь исходный код для всех модулей, который в нем содержится, плюс любые связанные с ним файлы определения интерфейсов, плюс сценарии, используемые для управления компиляцией и установки исполняемого файла. Однако, в виде особого исключения, распространяемый исходный код не нуждается во включении чего-либо, что обычно распространяется (либо в виде исходного кода, либо в бинарной форме) с главными компонентами (компилятором, ядром и т.д.) операционной системы, на которой исполняемый модуль запускается, если только этот компонент сам не сопровождает исполняемый модуль.

Если распространение исполняемого или объектного кода осуществляется путем предложения доступа к копированию из определенного места, в таком случае предложение эквивалентного доступа для копирования исходного кода из того же источника рассматривается как распространение исходного кода, даже если третья сторона не принуждается к копированию исходного кода вместе с объектным кодом.

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

5. От вас не требуется признавать данную Лицензию, поскольку вы не подписывали ее. Однако, ничто иное не дает вам прав на изменение или распространение Программы или производных от нее продуктов. Подобные действия запрещены законом, если вы не признаете данную Лицензию. Следовательно, фактом изменения или распространения Программы (или любого продукта на основе Программы) вы заявляете о своем признании данной Лицензии и всех содержащихся в ней требований и условий по копированию, распространению или изменению Программы или продуктов, основанных на ней.

6. Каждый раз при распространении Программы (или любого продукта, основанного на Программе), получатель автоматически становится обладателем лицензии от оригинального владельца авторских прав на копирование, распространение или изменение Программы в соответствии с данными требованиями и условиями. Вы не вправе налагать дополнительные ограничения на реализации предоставляемых здесь прав получателя. Вы не несете ответственности за обеспечение соблюдения третьей стороной данной Лицензии.

7. Если в результате судебного разбирательства или заявления о нарушении патентных прав, или по любой иной причине (не ограничиваясь вопросами патентов) на вас наложены ограничения (по предписанию суда, по соглашению или иные), которые противоречат условиям настоящей Лицензии, они не освобождают вас от условий данной Лицензии. Если вы не можете распространять Программу таким образом, чтобы одновременно выполнять свои обязательства в соответствии с настоящей Лицензией и с любыми другими относящимися к делу обязательствами, вы, как следствие, вовсе лишаетесь права распространять Программу. Например, если патентная лицензия не допускает безвозмездное распространение Программы всеми теми, кто прямо или косвенно получит от вас копии, единственным способом, с помощью которого вы можете удовлетворить и патентную лицензию, и данную Лицензию, будет полное воздержание от распространения Программы.

Если любая часть данного параграфа считается недействительной или не могущей быть выполненной в каких-либо конкретных обстоятельствах, должна применяться оставшаяся часть параграфа, а параграф в целом должен применяться в других условиях.

Целью данного параграфа не является склонить вас к нарушению каких-либо заявлений о патентных или иных правах собственности или оспорить любые такие заявления; единственная цель данного параграфа заключается в защите целостности системы распространения свободного программного обеспечения, которая реализуется практикой общедоступной лицензии. Многие люди сделали щедрый вклад в широкий спектр программного обеспечения, распространяемого посредством этой системы, в надежде на последовательное применение этой системы; делом автора/дарителя является решение, нужно ли распространять программу через любую другую систему, а обладатель лицензии не может повлиять на этот выбор.

Этот параграф нацелен на прояснение того, что подразумевается выводом оставшейся части настоящей Лицензии.

8. Если распространение и/или использование Программы в определенных странах ограничено либо патентами, либо охраняемыми авторским правом интерфейсами, ординальный владелец авторских прав, помещающий Программу под сферу влияния данной Лицензии, может добавить явные географические ограничения на распространение, исключающие эти страны, таким образом, чтобы распространение было разрешено лишь в не исключенных странах. В таком случае, данная Лицензия включает в себя это ограничение, как если бы оно было написано в тексте самой данной Лицензии.

9. Фонд свободного программного обеспечения время от времени может публиковать пересмотренные и/или новые версии Общедоступной Лицензии. Такие новые версии будут сходны по духу с настоящей версией, но могут отличаться в деталях для учета новых проблем или интересов.

Каждая версия получает отличительный номер версии. Если в Программе указан номер версии данной Лицензии, которая применяется к ней, и «любая последующая версия», вы имеете возможность соблюдать условия либо данной версии, либо любой последующей версии, опубликованной Фондом свободного программного обеспечения. Если в Программе не указан номер версии данной Лицензии, вы вправе выбрать любую версию, когда-либо публиковавшуюся Фондом свободного программного обеспечения.

10. Если вы хотите включить части Программы в другие свободные программы с иными условиями их распространения, напишите автору с просьбой о разрешении. Для программного обеспечения, авторским правом на которое обладает Фонд свободного программного обеспечения, напишите в Фонд свободного программного обеспечения, для этого мы иногда делаем исключения. Наше решение будет определяться двумя целями, сохранение свободного статуса всех производных от нашего свободного программного обеспечения и продвижение совместного и повторного использования программного обеспечения вообще.

Отказ от гарантий
11. ПОСКОЛЬКУ ДАННАЯ ПРОГРАММА ЛИЦЕНЗИРУЕТСЯ БЕСПЛАТНО, ДЛЯ НЕЕ НЕ ПРЕДОСТАВЛЯЕТСЯ НИКАКИХ ГАРАНТИЙ, В ТОЙ СТЕПЕНИ, НАСКОЛЬКО ЭТО ПРИМЕНИМО ПО ЗАКОНУ. ЕСЛИ ПИСЬМЕННО НЕ УКАЗАНО ИНОЕ, ВЛАДЕЛЬЦЫ АВТОРСКОГО ПРАВА И/ИЛИ ДРУГИЕ СТОРОНЫ ПРЕДОСТАВЛЯЮТ ПРОГРАММУ «КАК ЕСТЬ», БЕЗ ГАРАНТИЙ КАКОГО-ЛИБО РОДА, ВЫРАЖЕННЫХ ЯВНО ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЛ, НО НЕ ОГРАНИЧИВАЯСЬ ТОЛЬКО ЭТИМ, ПОДРАЗУМЕВАЕМЫМИ ГАРАНТИЯМИ ПОЛЕЗНОСТИ И ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. ВЕСЬ РИСК, КАСАЮЩИЙСЯ КАЧЕСТВА И ПРОИЗВОДИТЕЛЬНОСТИ ПРОГРАММЫ, ЛОЖИТСЯ НА ВАС. ЕСЛИ ПРОГРАММА ОКАЖЕТСЯ С НЕДОСТАТКАМИ, ВЫ БЕРЕТЕ НА СЕБЯ РАСХОДЫ ПО ВСЕМУ НЕОБХОДИМОМУ ОБСЛУЖИВАНИЮ, ВОССТАНОВЛЕНИЮ ИЛИ ИСПРАВЛЕНИЮ.

12. НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ, ЕСЛИ ТОЛЬКО ЭТО НЕ ТРЕБУЕТСЯ ПО СООТВЕТСТВУЮЩЕМУ ЗАКОНУ ИЛИ НЕ ОГОВОРЕНО ПО ПИСЬМЕННОМУ СОГЛАШЕНИЮ, НИ ОДИН ИЗ ВЛАДЕЛЬЦЕВ АВТОРСКИХ ПРАВ ИЛИ ЛЮБАЯ ДРУГАЯ СТОРОНА, КОТОРАЯ МОЖЕТ МОДИФИЦИРОВАТЬ И/ИЛИ РАСПРОСТРАНИТЬ ПРОГРАММУ НА ОГОВОРЕННЫХ ВЫШЕ УСЛОВИЯХ, НЕ БУДЕТ ОТВЕЧАТЬ ЗА ПРИЧИНЕННЫЙ ВАМ УЩЕРБ, ВКЛЮЧАЯ ЛЮБОЙ ОБЩИЙ, ОСОБЫЙ, СЛУЧАЙНЫЙ ИЛИ КОСВЕННЫЙ УЩЕРБ, ПОНЕСЕННЫЙ ОТ ИСПОЛЬЗОВАНИЯ ИЛИ НЕВОЗМОЖНОСТИ ИСПОЛЬЗОВАНИЯ ПРОГРАММЫ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ТОЛЬКО ЭТИМ, ПОТЕРИ ДАННЫХ ИЛИ НЕТОЧНЫЕ ОБРАБОТКИ ДАННЫХ ИЛИ ПОТЕРИ, КОТОРЫЕ ПОНЕСЛИ ВЫ ИЛИ ТРЕТЬИ ЛИЦА; ИЛИ НЕСПОСОБНОСТЬ ПРОГРАММЫ РАБОТАТЬ С ЛЮБЫМИ ДРУГИМИ ПРОГРАММАМИ), ДАЖЕ ЕСЛИ ВЛАДЕЛЕЦ АВТОРСКИХ ПРАВ ИЛИ ИНАЯ СТОРОНА БЫЛИ ПРЕДУПРЕЖДЕНЫ О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА.

КОНЕЦ ОПИСАНИЯ ПРАВ И ОБЯЗАННОСТЕЙ

Как применить эти условия договора к своим новым программам

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

Чтобы это сделать, добавьте к программе следующие уведомления. Надежнее всего добавить их в начало каждого исходного файла, чтобы наиболее эффективно сообщить об отказе от гарантий; и в каждом файле должна быть по крайней мере строка с «авторскими правами» и указанием на то, где можно найти полное уведомление.

одна строка с названием программы и описанием того, что она делает

Copyright (С) год имя автора

Эта программа является свободным программным продуктом; вы можете

распространять и/или изменять ее на условиях Общедоступной

лицензии GNU в том виде, как это опубликовано Фондом свободного

программного обеспечения; либо версии 2 Лицензии, либо

(по вашему выбору) любой последующей версии.

Данная программа распространяется в надежде, что она будет полезной,

но БЕЗ ВСЯКИХ ГАРАНТИЙ; в том числе без подразумеваемых гарантий

ПОЛЕЗНОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. Дополнительные

подробности см. в Общедоступной лицензии GNU.

Вместе с данной программой вы должны были получить копию

Общедоступной лицензии GNU; если вы ее не получили, напишите

в Фонд свободного программного обеспечения:

Free Software Foundation, Inc., 59 Temple Place,

Suite 330, Boston, MA 20111, USA.

Добавьте также сведения о том, как связаться с вами по электронной или обычной почте.

Если программа интерактивная, вставьте в ее вывод при запуске краткое уведомление, подобное данному:

Gnomovision version 69, Copyright (С) год имя_автора

Gnomovision поставляется БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; чтобы получить

подробности, наберите 'show w'. Это свободный программный продукт,

и вы можете распространять его при определенных условиях;

наберите 'show c', чтобы получить дополнительные сведения.

Гипотетические команды 'show w' и 'show c' должны отображать соответствующие части Общедоступной лицензии. Конечно, используемые вами команды могут называться как-нибудь иначе, а не 'show w' и 'show c'; они могут быть даже щелчками мышью или пунктами меню — всем, что лучше подходит вашей программе.

Вам следует также получить от вашего нанимателя (если вы работаете программистом) или учебного заведения, если оно имеется, заявление об «отказе от авторских прав» для программы, если это необходимо. Вот образец; измените имена:

Yoyodyne, Inc., настоящим отказывается от всех авторских прав

на программу 'Gnomovision' (которая работает с компиляторами),

написанной James Hacker.

подпись Ty Coon, 1 апреля 1989

Ty Coon, вице-президент

Данная Общедоступная лицензия не разрешает включать вашу программу в частные программы. Если ваша программа представляет собой библиотеку процедур, вы можете счесть более полезным разрешить компоновку частных приложений с данной библиотекой. Если это то, что вам нужно, используйте вместо данной Лицензии Малую общедоступную библиотечную лицензию GNU.

Пример использования

Данный раздел не является частью GPL. Здесь мы показываем комментарий с заявлением об авторских правах из программы GNU env:

/* env - run a program in a modified environment

Copyright (C) 1986, 1991-2002 Free Software Foundation, Inc.

This program is free software; you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2, or (at your option)

any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public License

along with this program; if not, write to the Free Software Foundation,

inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */

Это обычное использование. Оно содержит следующие, в сущности, стереотипные элементы:

• Одну строку комментария с названием и описанием программы. В более крупных программах здесь может быть название и описание файла внутри программы.

• Заявление об авторских правах.

• Два параграфа с объяснением и отказом от гарантий.

• Где получить копию GPL.

Примечания

1

Это знаменитое высказывание было сделано на Международном симпозиуме по эффективному производству больших программ в Jablonna, Польша, 10-14 августа 1970 г. — Примеч. автора.

(обратно)

2

http://www.ansi.orgПримеч. автора.

(обратно)

3

http://www.iso.chПримеч. автора.

(обратно)

4

http://www.opengroup.orgПримеч. автора.

(обратно)

5

http://www.gnu.orgПримеч. автора.

(обратно)

6

Игра слов: free — свободный, бесплатный — Примеч. перев.

(обратно)

7

В оригинале: «Rome wasn't built in a day» — Примеч. перев.

(обратно)

8

См. справочные страницы csh(1) и tcsh(1) и книгу Using csh & tcsh, by Paul DuBois, O'Reilly & Associates. Sebastopol, CA. USA, 1995. ISBN 1-56592-132-1 — Примеч. автора.

(обратно)

9

Соответствующие справочные страницы можно посмотреть с помощью man 1 awk и man 3 printf — Примеч. науч. ред.

(обратно)

10

http://www.southern-storm.com.au/v7upgrade.htmlПримеч. автора.

(обратно)

11

Некоторые системы позволяют рядовым пользователям назначать владельцем их файла кого-нибудь еще, таким образом «отдавая его». Детали определяются стандартом POSIX, но они несколько запутаны. Обычная конфигурация GNU/Linux не допускает этого — Примеч. автора.

(обратно)

12

Конечно, владелец всегда может изменить права доступа. Большинство пользователей не отменяют для себя нрава на запись — Примеч. автора.

(обратно)

13

Для этого правила есть несколько редких исключений, но все они выходят за рамки данной книги — Примеч. автора.

(обратно)

14

Эта особенность впервые появилась в Multics, но Multics никогда широко не использовался — Примеч. автора.

(обратно)

15

Процесс может быть приостановлен, в этом случае он не «работающий»; но он и не завершён. В любом случае, на ранних этапах восхождения по кривой обучения не стоит быть слишком педантичным — Примеч. автора.

(обратно)

16

Так называемые переменные окружения — Примеч. науч. ред.

(обратно)

17

Между народный стандарт ISO/IEC 9899-1990 описывает разновидность языка С известную также как C89 или C90 — Примеч. науч. ред.

(обратно)

18

Стандарт C99 (ISO/IЕС 9899-1999) — Примеч. науч. ред.

(обратно)

19

Этот раздел адаптирован из статьи автора, который издавался в выпуске 16 Linux Journal (См. http://www.linuxjournal.com/article.php?sid=1135) Перепечатано и адаптировано по разрешению — Примеч. автора.

(обратно)

20

Это утверждение относится к ядру HURD, которое все еще находится в стадии разработки (в начале 2004 г.) Разработка на основе GCC и библиотеки GNU С (GLIBC) сегодня имеет место большей частью на Linux-системах — Примеч. автора.

(обратно)

21

Стиль расположения кода, рекомендуемый фондом свободного программного обеспечения (Free Software Foundation) — Примеч. науч. ред.

(обратно)

22

Эта ситуация имела место примерно в 1993 г; трюизм даже более очевиден сегодня, когда пользователи обрабатывают с помощью gawk гигабайты протокольных файлов — Примеч. автора.

(обратно)

23

Раздел 13.4, «Не могли бы вы произнести это для меня по буквам?», с. 521, дает обзор многобайтных символов и кодировок — Примеч. автора.

(обратно)

24

Механика проверки ошибок и сообщений о них обсуждаются в разделе 4.3, «Обнаружение неправильной работы» — Примеч. автора.

(обратно)

25

Русский перевод Брайан Керниган, Денис Ритчи. Язык программирования Си (изд. 3-е, исправленное) Санкт- Петербург. Невский диалект, 2001 — Примеч. науч. ред.

(обратно)

26

http://www.gnu.org/gnu/thegnuproject.htmlПримеч. автора.

(обратно)

27

Имя команды — ls в данном примере, так же доступно программе в качестве аргумента — Примеч. науч. ред.

(обратно)

28

См. /usr/src/cmd/echo.c в дистрибутиве V7 — Примеч. автора.

(обратно)

29

Когда мы спросили Джима Мейеринга (Jim Meyering), сопроводителя Coreulils, о наличии register в GNU Coreutils, он дал нам интересный ответ. Он удаляет эти слова при изменении кода, но в остальных случаях оставляет их на месте, чтобы облегчить интеграцию сделанных изменений с существующими версиями — Примеч. автора.

(обратно)

30

См. http://sources.redhat.comПримеч. автора.

(обратно)

31

http://plan9.bell-labs.com/magic/man2html/2/argПримеч. автора.

(обратно)

32

http://www.gnu.org/manual/glibc/html_node/Argp.htmlПримеч. автора.

(обратно)

33

http://256.com/sources/argvПримеч. автора.

(обратно)

34

http://autogen.sourceforge.net/autoopts.htmlПримеч. автора.

(обратно)

35

ftp://ftp.gnu.org/gnu/gengetopt/Примеч. автора.

(обратно)

36

http://nis-www.lanl.gov/~jt/Software/opt/opt-3.19.tar.gzПримеч. автора.

(обратно)

37

http://freshmeat.net/projects/popt/?topic_id=809Примеч. автора.

(обратно)

38

Существует также другое название для этой области данных — Неинициализированные данные — Примеч. науч. ред.

(обратно)

39

BSS означает 'Block Started by Symbol', мнемоника из ассемблера IBM 7094 — Примеч. автора.

(обратно)

40

Дамп ядра (core dump) является образом запущенного процесса в памяти, который создаётся при неожиданном завершении процесса. Позже этот дамп может быть использован для отладки Unix-системы, называют это файл core, а системы GNU/Linux — core.pid, где pid — ID потерпевшего крушения процесса — Примеч. автора.

(обратно)

41

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

(обратно)

42

Он получен от реальной практики работы с gawkПримеч. автора.

(обратно)

43

Этот код несет с собой аромат практического опыта, не удивительно было узнать, что более ранние версии просто проверяли наличие обратного слеша перед символом конца строки, пока кто-то не пожаловался, что он не работает, когда в конце строки есть несколько обратных слешей — Примеч. автора.

(обратно)

44

Эта функция завершает выполнение программы — Примеч. науч. ред.

(обратно)

45

alloca(3) — Примеч. науч. ред.

(обратно)

46

open() является одним из немногих варьирующих (variadic) системных вызовов — Примеч. автора.

(обратно)

47

См. /usr/src/cmd/cat.c в дистрибутиве V7. Программа без изменений компилируется для GNU/Linux. — Примеч. автора.

(обратно)

48

По крайней мере, три из этих блоков содержат данные, которые мы записали, другие для использования операционной системой при отслеживании размещения этих данных — Примеч. автора.

(обратно)

49

Да, это пишется так. Кена Томпсона (Ken Thompson), одного из двух «отцов» Unix, однажды спросили, что бы он сделал по-другому, если бы ему пришлось переделать Unix. Он ответил, что написал бы creat() с «e» на конце. И в самом деле, именно это он сделал для операционной системы Plan 9 From Bell LabsПримеч. автора.

(обратно)

50

Если у вас нет UPS и вы используете систему для критической работы, мы настоятельно рекомендуем вам обзавестись им. Следует также регулярно делать резервные копии. — Примеч. автора.

(обратно)

51

Состояние .гонки (race condition) является ситуацией, при которой детали временных соотношений могут вызывать непреднамеренные побочные эффекты или ошибки. В данном случае, каталог в течение короткого периода времени находится в противоречивом состоянии, и именно эта противоречивость и создаёт уязвимость — Примеч. автора.

(обратно)

52

Конечно, меняются служебные данные файла (число ссылок), но это не влияет ни на какой другой атрибут файла, также, как не влияет на содержимое файла. Обновление счетчика ссылок на файл является единственной операцией над файлом, при которой не проверяются права доступа к файлу — Примеч. автора.

(обратно)

53

См /usr/src/cmd/rmdir с в дистрибутиве V7 — Примеч. автора.

(обратно)

54

То есть прочитаны все элементы каталога — Примеч. науч. ред.

(обратно)

55

В системах GNU/Linux могут монтироваться файловые системы многих операционных систем, не относящихся к Unix. Во многих коммерческих системах Unix также можно смонтировать файловые системы MS-DOS. В таких случаях предположения относительно файловых систем Unix неприменимы — Примеч. автора.

(обратно)

56

Стоит внимательно подумать прежде чем использовать эти функции — Примеч. науч. ред.

(обратно)

57

Linux использует блочные устройства исключительно для дисков. Другие системы используют оба типа — Примеч. автора.

(обратно)

58

Именованные каналы и сокеты были разработаны независимо группами Unix System V и BSD соответственно. Когда системы Unix вновь сошлись, обе разновидности файлов стали доступными универсально —- Примеч. автора.

(обратно)

59

Технический термин warm fuzzyПримеч. автора.

(обратно)

60

Это утверждение было верно для V7, на современных системах больше нет таких гарантий — Примеч. автора.

(обратно)

61

Спасибо Джиму Мейерингу (Jim Meyering) за объяснение проблем — Примеч. автора.

(обратно)

62

UTC представляет собой независимое от языка сокращение для Coordinated Universal Time (универсальное скоординированное время). Старый код (а иногда и люди постарше) называют это Гринвичским временем (Greenwich Mean Time, GMT), которое является временем в Гринвиче, Великобритания. Когда стали широко использоваться часовые пояса, в качестве точки отсчета, относительно которого все остальные часовые пояса отсчитывались либо вперед, либо назад, был выбран Гринвич — Примеч. автора.

(обратно)

63

fchown() и fchmod() были введены в 4 2 BSD, но не включались в System V до выпуска 4 — Примеч. автора.

(обратно)

64

a.m. — от ante meridiem (до полудня), p.m. — от post meridiem (пополудни), американская система обозначения 12-часового цикла времени суток. — Примеч. перев.

(обратно)

65

Хотя POSIX стандартизует формат TZ, он не представляет интереса, поэтому мы не стали возиться здесь с его документированием. В конце концов, именно tzset() должна понимать формат, а не код пользователя. Реализации могут использовать и используют форматы, которые расширяют POSIX — Примеч. автора.

(обратно)

66

Вывод, показанный здесь, относится к US Eastern Standard Time. Вы получите различные результаты для одних и тех же программ и данных, если используете другой часовой пояс — Примеч. автора.

(обратно)

67

STL (Standard Template Library, стандартная библиотека шаблонов). — Примеч. науч. ред.

(обратно)

68

Заметным исключением является лишь Sun Solaris, где эти две функции существуют лишь в трудной для использования библиотеке совместимости с BSD — Примеч. автора.

(обратно)

69

Типичные сетевые базы данных включают Network Information Service (NIS) и NIS+ от Sun Microsystems, Kerberos (Hesiod), MacOS X NetInfo (версии вплоть до и включая 10.2) и LDAP, Lightweight Directory Access Protocol. Системы BSD хранят сведения в базах данных на диске и автоматически создают файлы /etc/passwd и /etc/groupПримеч. автора.

(обратно)

70

К сожалению, еслипроизводительность является проблемой, нет стандартных способов узнать, как ваша библиотека осуществляет работу, а на самом деле способ ее работы может варьировать во время исполнения! (См. справочную страницу nsswitchconf(5) в системе GNU/Linux.) С другой стороны, назначением API помимо всего прочего является сокрытие деталей — Примеч. автора.

(обратно)

71

Русский перевод Дональд E. Кнут. Искусство программирования Том 3. Сортировка и поиск (2-е издание). Москва • Санкт-Петербург • Киев, Вильямс, 2000 — Примеч. науч. ред.

(обратно)

72

http://www/gtk.orgПримеч. автора.

(обратно)

73

http://www.gnome.orgПримеч. автора.

(обратно)

74

http://www/gtk.org/rdpПримеч. автора.

(обратно)

75

В C++ это по-другому: там символьные константы действительно имеют тип char. Это различие не влияет на данный конкретный код — Примеч. автора.

(обратно)

76

GNU/Linux и Solaris дают возможность монтировать один файл поверх другого; это продвинутое использование, которое мы не будем обсуждать — Примеч. автора.

(обратно)

77

Например, при обновлении VAX 11/780 с 4.1 BSD до 4.2 BSD — Примеч. автора.

(обратно)

78

System V Release 3 поддерживала два различных размера блоков: 512 байтов и 1024 байта, но в остальном организация диска была той же самой — Примеч. автора.

(обратно)

79

Университет Карнеги-Меллона — Примеч. перев.

(обратно)

80

Источник: http://www.ife.ee.ethz.ch/music/software/sag/subsection2_5_4_3.htmlПримеч. автора.

(обратно)

81

Ha GNU/Linux и большинстве систем Solaris и некоторые системы на основе System V Release 4 используют /etc/vfstab, возможно, с другим форматом — Примеч. автора.

(обратно)

82

См. /usr/include/bits/statvfs.h на системе GNU/Linux — Примеч. автора.

(обратно)

83

На системах GNU/Linux и BSD для получения нижележащего дескриптора файла можно применить функцию dirfd() к указателю DIR*, см. справочную страницу GNU/Linux dirfd(3) — Примеч. автора.

(обратно)

84

POSIX стандартизировал ftw() для поддержки существующего кода, а GNU/Linux b коммерческие системы Unix продолжают её поддерживать. Однако, поскольку она недостаточно функциональна, мы не будем больше ее обсуждать. Если интересуетесь, см. ftw(3). — Примеч. автора.

(обратно)

85

У некоторых старых версий GLIBC были проблемы с FTW_CHDIR. Это не относится к GLIBC 2.3.2 и более поздним, и маловероятно, что вы столкнетесь с проблемами — Примеч. автора.

(обратно)

86

Мы не знаем, почему кому-нибудь может понадобиться делать такое изменение, но философия «что вы просили, то и получили» применяется и здесь! — Примеч. автора.

(обратно)

87

Хэш-таблица является структурой данных, позволяющей быстрое получение сохраненной информации, подробности выходят за рамки данной книги — Примеч. автора.

(обратно)

88

Fork (англ.) — «n вилка, развилка, v разветвлять, ответвлять» — Примеч. перев.

(обратно)

89

Такие процессы часто демонстрируют детское поведение. — Примеч. автора.

(обратно)

90

См. 9.1.4.3 Имена программ и argv[0]Примеч. науч. ред.

(обратно)

91

Мы это не придумываем. Терминология, конечно, не совсем правильна, но таким было чувство юмора разработчиков оригинальной Unix — Примеч. автора.

(обратно)

92

Дважды проверьте справочную страницу getrusage(2), если у вас более новое ядро, поскольку это поведение, возможно, изменилось — Примеч. автора.

(обратно)

93

csh и tcsh также могут быть включены в эту категорию, но мы предпочитаем оболочки в стиле оболочки Борна — Примеч. автора.

(обратно)

94

Такая операция часто обозначается no-op — «no operation» (нет операции) — Примеч. автора.

(обратно)

95

Мы уверены, что вы не волновались. В конце концов, вы, возможно, используете конвейеры из оболочки десятки раз в день — Примеч. автора.

(обратно)

96

Что они ели на обед, остается не указанным. — Примеч. автора.

(обратно)

97

FIFO означает «first in, first out» — «первым вошел, первым вышел». Так работают каналы. — Примеч. автора.

(обратно)

98

На системах GNU/Linux /dev/fd является символической ссылкой на /proc/self/fd, но поскольку /dev/fd является общеизвестным, в своем коде следует использовать именно его — Примеч. автора.

(обратно)

99

Хотя мы показали простые команды, допустимы произвольные конвейеры — Примеч. автора.

(обратно)

100

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

(обратно)

101

Ну, мы игнорируем мысль, что два супруга могли бы хотеть поговорить друг с другом и насладиться компанией — Примеч. автора.

(обратно)

102

В одно и то же время есть только один сопроцесс по умолчанию (доступный посредством 'read -p' и 'print -p'). Сценарии оболочки могут использовать команду exec со специальной записью перенаправления для назначения дескрипторов файла сопроцесса определенным номерам. После этого можно запустить другой сопроцесс — Примеч. автора.

(обратно)

103

Очевидно, вы можете их закрыть. Но если вы не знаете, что они открыты, они теряются с таким же успехом, как и память через утечку памяти — Примеч. автора.

(обратно)

104

Игра слов kill-overkill (избыточно — overkill) — Примеч. перев.

(обратно)

105

По крайней мере один поставщик дистрибутивов GNU/Linux отменяет сознание файлов core «с иголочки». Для повторного подключения этой возможности поместите в свой файл ~/.profile строку 'ulimit -S -с unlimited' — Примеч. автора.

(обратно)

106

Handler (англ.) — обработчик — Примеч. перев.

(обратно)

107

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

(обратно)

108

Хотя мы описываем read(), эти правила применяются ко всем системным вызовам, которые могут завершиться с ошибкой EINTR, как, например, семейство функций wait()Примеч. автора.

(обратно)

109

Для использования API требуется компоновка с отдельной библиотекой, — ljobsПримеч. автора.

(обратно)

110

Насколько мы смогли определить, имена SA_NOMASK и SA_ONESHOT являются специфическими для GNU/Linux. Если кому-нибудь известно иное, пожалуйста, сообщите нам!

(обратно)

111

Наша благодарность Ульриху Дрепперу (Ulrich Drepper) за помощь в разъяснении, связанных с этим проблем — Примеч. автора.

(обратно)

112

Исторически системы BSD использовали имя SIGCHLD, которое используется и POSIX. В System V есть сходный сигнал с именем SIGCLD. GNU/Linux определяет последний через #define как первый — см. табл. 10.1 — Примеч. автора.

(обратно)

113

Возможно, лучшим именем для функции было бы child_at_school() [ребенок_в_школе] — Примеч. автора.

(обратно)

114

MacOS X и Windows XP обе являются многопользовательскими системами, но это довольно недавние разработки — Примеч. автора.

(обратно)

115

Хотя в Соединенных Штатах нет официальных удостоверений личности, во многих странах они имеются — Примеч. автора.

(обратно)

116

Денис Ричи (Dennis Ritchie), создатель С и соавтор Unix, получил патент для бита setuid: Protection of Data File Contents (Защита содержимого файла данных), номер патента США 4135240. См. http://www.delphion.com/details?pn=US04135240__, а также http://www.uspco.gov. AT&T передала патент общественности, разрешив всем использовать свою технологию — Примеч. автора.

(обратно)

117

Безопасность для систем GNU/Linux и Unix является глубокой темой сама по себе. Это просто пример. см. раздел 11.9 «Рекомендуемая литература» — Примеч. автора.

(обратно)

118

Одной из программ, разработанных с этой целью, является GNU userv (ftp://ftp.gnu.org/gnu/userv/) — Примеч. автора.

(обратно)

119

На ум приходят образы счастливых юных программ их лица и руки, запачканные шоколадом — Примеч. автора.

(обратно)

120

E (Effective) эффективный ID, R (Real) действительный ID и S (Saved) сохраненный ID — Примеч. науч. ред.

(обратно)

121

Однако, в своей лекции в честь присуждения премии Тьюринга Ассоциации по вычислительной технике в 1981 г. д-р Хоар утверждает, что эту идею выдвинул сам Алан Тьюринг — Примеч. автора.

(обратно)

122

Как упоминалось в разделе 10.2 «Действия сигналов», некоторые дистрибутивы GNU/Linux запрещают создание файлов core. Чтобы снова разрешить их, поместите в свой файл ~/.profile строку 'ulimit -S -с unlimited' — Примеч. автора.

(обратно)

123

Hints On Programming Language Design, C.A.R. Hoare Stanford University Computer Science Technical Report CS-73-403 (ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/73/403/CS-TR-73-403.pdf). December, 1973 — Примеч. автора.

(обратно)

124

См. (1). wc подсчитывает строки, слова и символы — Примеч. автора.

(обратно)

125

Такое использование /dev/shm на самом деле является злоупотреблением,, он предназначен для использования в реализации разделяемой памяти, а не в качестве электронного диска. Тем не менее, это полезно для иллюстрации нашей мысли — Примеч. автора.

(обратно)

126

На нашей системе 512 мегабайтов оперативной памяти, что для старых чудаков вроде автора кажется порядочным. Однако цены на память упали, и вполне обычны системы с одним или более гигабайтами оперативной памяти, по крайней мере, для разработчиков программного обеспечения — Примеч. автора.

(обратно)

127

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

(обратно)

128

Такая утечка была у нас в gawk К счастью, она исправлена — Примеч. автора.

(обратно)

129

Numerical Recipes in С. The Art of Scientific Computing,, 2nd edition, by William H. Press, Brian P. Plannery, Saul A. Teukolsky, and William T. Vetterling. Cambridge University Press, USA, 1993, ISBN 0-521-43108-5 — Примеч. автора.

(обратно)

130

См /usr/source/s1/glob.c в дистрибутиве V6

(обратно)

131

http://www.cs.bell-labs.com/cm/cs/pearls/Примеч. автора.

(обратно)

132

Русский перевод: Дональд E. Кнут. Искусство программирования. Том 2. Получисленные алгоритмы (3-е издание). Москва - Санкт-Петербург - Киев. Вильямс. 2000 — Примеч. науч. ред.

(обратно)

133

http://www-cs-faculty.stanford.edu/~knuth/taocp.htmlПримеч. автора.

(обратно)

134

Русский перевод — Дж. Фридл. Регулярные выражения (2-е издание). C.-Петербург, Питер, 2003 — Прим. науч. ред.

(обратно)

135

http://www.gnu.org/software/grep/doc/grep.htmlПримеч. автора.

(обратно)

136

От английских слов i(nternationalizatio)n и l(ocalizatio)n —Примеч. перев.

(обратно)

137

NLS — native language support — Примеч. перев.

(обратно)

138

Существует более ранний дизайн, известный как catgets(). Хотя он стандартизован POSIX, его гораздо сложнее использовать, и мы его не рекомендуем — Примеч. автора.

(обратно)

139

Программисты, долгое время работавшие на С и Unix, могут предпочесть использовать локаль 'С', даже если их родной язык английский, английские локали дают другой результат по сравнению с тем, что ожидают эти седые, понюхавшие пороху ветераны Unix — Примеч. автора.

(обратно)

140

Мы так же счастливы, как и вы, поскольку нам не нужно представлять код, использующий эту полнофункциональную структуру — Примеч. автора.

(обратно)

141

В стандарте используется технический термин radix point (позиционный разделитель), поскольку числа с другим основанием счисления также могут иметь дробные части. Однако, для денежных значений можно довольно безопасно использовать термин 'decimal point' (десятичный разделитель) — Примеч. автора.

(обратно)

142

Нам, вероятно, следовало выбрать более осмысленные имена вместо простых ii и jj, поскольку использующий их код короткий, отсутствие у нас воображения не представляет значительной проблемы — Примеч. автора.

(обратно)

143

Это устанавливается механизмом Autoconf и Automake. Autoconf и Automake являются мощными программными наборами, дающими возможность поддержки широкого круга Unix-систем систематическим образом — Примеч. автора.

(обратно)

144

Хотя американцы часто ссылаются на эры определенных президентов, они не являются частью национального календаря в том же смысле, как в Японии до Второй мировой войны или в докоммунистическом Китае — Примеч. автора.

(обратно)

145

Подробности приведены в документации GNU gettext. Здесь мы концентрируемся на потребностях разработчика, а не переводчика — Примеч. автора.

(обратно)

146

Этот макрос обычно определяется автоматически программой configure, либо в специальном заголовке, либо в командной строке компилятора configure создается с помощью Autoconf и Automake — Примеч. автора.

(обратно)

147

Pig — свинья, поросенок (англ.) — Примеч. перев.

(обратно)

148

Мы тщетно потратили 30 или 45 минут, пытаясь использовать каталог piglat/LC_MESSAGES и установку LC_ALL=piglat' без всякого успеха, пока не выяснили это — Примеч. автора.

(обратно)

149

ftp://ftp.gnu.org/gnu/gettextПримеч. автора.

(обратно)

150

http://www.unicode.orgПримеч. автора.

(обратно)

151

GNU/Linux ее поддерживает, но лишь для совместимости — Примеч. автора.

(обратно)

152

Справочная страница GNU/Linux fcntl(3) указывает, что этих сведений может быть недостаточно, процесс может находиться на другой машине! При блокировках по сети есть и другие проблемы, в общем, использование блокировки в файловых системах, смонтированных для удаленных компьютеров, не является удачной мыслью — Примеч. автора.

(обратно)

153

В системе GNU/Linux lockf() реализована в виде «оболочки» вокруг fcntl()Примеч. автора.

(обратно)

154

Тупик (deadlock) является ситуацией, при которой оба процесса блокируются, причем каждый из них ждёт, пока другой освободит определенный ресурс — Примеч. автора.

(обратно)

155

Удачно, что название flock() отличается от lockf(), поскольку их семантика различна. Это также страшно сбивает с толку. Держите свое руководство под рукой. — Примеч. автора.

(обратно)

156

В справочной странице gettimeofday(2) документирована соответствующая функция settimeofday() для использования суперпользователем (root) для установки времени дня всей системы — Примеч. автора.

(обратно)

157

К сожалению, по-видимому, в настоящее время нет стандарта для названий членов struct stat, что делает такую операцию непереносимой — Примеч. автора.

(обратно)

158

Корректное выполнение профилировки нетривиальная задача, если вы думаете о написании интерпретатора, стоит сначала провести свои исследования — Примеч. автора.

(обратно)

159

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

(обратно)

160

Этот вывод для часового пояса U.S. Eastern Time zone — Примеч. автора.

(обратно)

161

Оптимизации компилятора являются общеизвестным козлом отпущения для логических ошибок. В прошлом обвинения компиляторов были более оправданы. Судя по нашему опыту, используя современные системы и компиляторы, очень редко можно обнаружить случаи, в которых оптимизации компилятора привносят ошибки в работающий код — Примеч. автора.

(обратно)

162

Мы говорим об оригинальном BSD dbx. В течение десяти лет мы использовали исключительно GDB — Примеч. автора.

(обратно)

163

ddd поставляется со многими системами GNU/Linux. Исходный код доступен на FTP-сайте проекта GNU ddd (ftp://ftp.gnu.org/gnu/ddd/) — Примеч. автора.

(обратно)

164

http.//sources.redhat.com/insight/ — Примеч. автора.

(обратно)

165

ftp://ftp.gnu.org/gnu/gdb/Примеч. автора.

(обратно)

166

http://www.gnu.orgПримеч. автора.

(обратно)

167

Если вы хотите изменить такое поведение, см. sysctl(8) — Примеч. автора.

(обратно)

168

Примерно 213×275 мм — Примеч. перев.

(обратно)

169

Bjarne Stroustrup, создатель С++, настойчиво работал над тем, чтобы сделать использование препроцессора С совершенно ненужным в С++. По нашему мнению, он не вполне добился успеха: #include нужен до сих пор, но не обычные макросы. Для С препроцессор остается ценным и инструментом, но он должен использоваться благоразумно — Примеч. автора.

(обратно)

170

Серьезно! Часто люди пропускают через gawk мегабайты данных. Помните, никаких произвольных ограничений! — Примеч. автора.

(обратно)

171

Мы унаследовали эту схему. В общем, она работает, но все же есть проблемы. Целью данного раздела является передача накопленного нами в ходе работы с объединениями опыта — Примеч. автора.

(обратно)

172

Опять-таки, GCC 3.1 или более новый и GDB 5 дают возможность непосредственного использования макросов, но только лишь если вы используете их совместно, с определенными опциями. Это было описано ранее в разделе 15.4.1.2 «По возможности избегайте макросов с выражениями». — Примеч. автора.

(обратно)

173

Эта часть кода была с тех пор пересмотрена, поэтому там больше нет этих строк из примера. — Примеч. автора.

(обратно)

174

Переписав код управления буфером! — Примеч. автора.

(обратно)

175

ftp://ftp.ninemoons.corn/pub/dbug/Примеч. автора.

(обратно)

176

В C99, который допускает смешивание объявлений переменных с исполняемым кодом, это составляет меньшую проблему, но помните, что этот пакет был разработан для K&R С — Примеч. автора.

(обратно)

177

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

(обратно)

178

ftp://ftp.perens.com/pub/ElectricFenceПримеч. автора.

(обратно)

179

GDB также позволяет определить переменную окружения LD_PRELOAD: set environment LD_PRELOAD=PATH_TO_YOUR_LIBRARY — Примеч. науч. ред.

(обратно)

180

http://www.dmalloc.comПримеч. автора.

(обратно)

181

Все в большей степени для разработки высококачественных продуктов используется также GNU/Linux! — Примеч. автора.

(обратно)

182

http://www.winehq.comПримеч. автора.

(обратно)

183

http://valgrind.kde.orgПримеч. автора.

(обратно)

184

http://www.linuxjournal.com/article.php?sid=6059Примеч. автора.

(обратно)

185

http://www.linuxjournal.com/article.php?sid=6556Примеч. автора.

(обратно)

186

http://www.splint.orgПримеч. автора.

(обратно)

187

http://www.debuggingrules.comПримеч. автора.

(обратно)

188

http://www.amacombooks.orgПримеч. автора.

(обратно)

189

http://www.cs.bell-labs.com/cm/cs/pearls/Примеч. автора.

(обратно)

190

Русский перевод Брайан Керниган, Роб Пайк. UNIX: Программное окружение. Санкт-Петербург. Символ-Плюс, 2003 — Примеч. науч. ред.

(обратно)

191

Это приложение приведено в буквальном виде с веб-страницы, указанной вначале — Примеч. автора.

(обратно)

192

http://www1.neweb.ne.jp/wa/yamdas/column/technique/21-daysj.htmlПримеч. автора.

(обратно)

193

http://loro.sf.net/notes/21-dias.htmlПримеч. автора.

(обратно)

194

Это — неофициальный перевод Лицензии Caldera для старой Unix на русский язык. Он не был опубликован Caldera International, Inc и не может легально определять условия распространения программных продуктов, использующих Лицензию Caldera — только оригинальный английский текст Лицензии Caldera для старой Unix имеет законную силу.

(обратно)

195

Это — неофициальный перевал Общедоступной лицензии GNU на русский язык. Он не был опубликован Фондом Свободного Программного Обеспечения и не может легально определять условия распространения программных продуктов, использующих Общедоступную лицензию GNU — только оригинальный английский текст Общедоступной лицензии GNU имеет законную силу.

(обратно)

Оглавление

  • Предисловие
  • Часть 1 Файлы и пользователи
  •   Глава 1 Введение
  •     1.1. Модель файловой системы Linux/Unix
  •       1.1.1. Файлы и права доступа
  •       1.1.2. Каталоги и имена файлов
  •       1.1.3. Исполняемые файлы
  •       1.1.4. Устройства
  •     1.2. Модель процессов Linux/Unix
  •       1.2.1. Каналы: сцепление процессов
  •     1.3. Стандартный С против оригинального С
  •     1.4. Почему программы GNU лучше
  •       1.4.1. Проектирование программ
  •       1.4.2. Поведение программы
  •       1.4.3. Программирование на С
  •       1.4.4. Вещи, которые делают программы GNU лучше
  •       1.4.5. Заключительные соображения по поводу «GNU Coding Standards»
  •     1.5. Пересмотренная переносимость
  •     1.6. Рекомендуемая литература
  •     1.7. Резюме
  •     Упражнения
  •   Глава 2 Аргументы, опции и переменные окружения
  •     2.1. Соглашения по опциям и аргументам
  •       2.1.1. Соглашения POSIX
  •       2.1.2. Длинные опции GNU
  •     2.2. Базовая обработка командной строки
  •       2.2.1. Программа echo V7
  •     2.3. Разбор опций: getopt() и getopt_long()
  •       2.3.1. Опции с одним символом
  •       2.3.2. GNU getopt() и порядок опций
  •       2.3.3. Длинные опции
  •         2.3.3.1. Таблица длинных опций
  •         2.3.3.2. Длинные опции в стиле POSIX
  •         2.3.3 3. Сводка возвращаемых значений getopt_long()
  •         2.3.3.4. GNU getopt() или getopt_long() в программах пользователей
  •     2.4. Переменные окружения
  •       2.4.1. Функции управления окружением
  •       2.4.2. Окружение в целом: environ
  •       2.4.3. GNU env
  •     2.5. Резюме
  •     Упражнения
  •   Глава 3 Управление памятью на уровне пользователя
  •     3.1. Адресное пространство Linux/Unix
  •     3.2. Выделение памяти
  •       3.2.1. Библиотечные вызовы: malloc(), calloc(), realloc(), free()
  •         3.2.1.1. Исследование подробностей на языке С
  •         3.2.1.2. Начальное выделение памяти: malloc()
  •         3.2.1.3. Освобождение памяти: free()
  •         3.2.1.4. Изменение размера: realloc()
  •         3.2.1.5. Выделение с инициализацией нулями: calloc()
  •         3.2.1.6. Подведение итогов из GNU Coding Standards
  •         3.2.1.7. Использование персональных программ распределения
  •         3.2.1.8. Пример: чтение строк произвольной длины
  •         3.2.1.9. Только GLIBC: чтение целых строк: getline() и getdelim()
  •       3.2.2. Копирование строк: strdup()
  •       3.2.3. Системные вызовы: brk() и sbrk()
  •       3.2.4. Вызовы ленивых программистов: alloca()
  •       3.2.5. Исследование адресного пространства
  •     3.3. Резюме
  •     Упражнения
  •   Глава 4 Файлы и файловый ввод/вывод
  •     4.1. Введение в модель ввода/вывода Linux/Unix
  •     4.2. Представление базовой структуры программы
  •     4.3. Определение ошибок
  •       4.3.1. Значения errno
  •       4.3.2. Стиль сообщения об ошибках
  •     4.4. Ввод и вывод
  •       4.4.1. Понятие о дескрипторах файлов
  •       4.4.2. Открытие и закрытие файлов
  •         4.4.2.1. Отображение переменных FILE* на дескрипторы файлов
  •         4.4.2.2. Закрытие всех открытых файлов
  •       4.4.3. Чтение и запись
  •       4.4.4. Пример: Unix cat
  •     4.5. Произвольный доступ: перемещения внутри файла
  •     4.6. Создание файлов
  •       4.6.1. Определение начальных прав доступа к файлу
  •       4.6.2. Создание файлов с помощью creat()
  •       4.6.3. Возвращаясь к open()
  •     4.7. Форсирование записи данных на диск
  •     4.8. Установка длины файла
  •     4.9. Резюме
  •     Упражнения
  •   Глава 5 Каталоги и служебные данные файлов
  •     5.1. Просмотр содержимого каталога
  •       5.1.1. Определения
  •       5.1.2. Содержимое каталога
  •       5.1.3. Прямые ссылки
  •         5.1.3.1. Программа GNU link
  •         5.1.3.2. Точка и точка-точка
  •       5.1.4. Переименование файлов
  •       5.1.5. Удаление файла
  •         5.1.5.1. Удаление открытых файлов
  •         5.1.5.2. Использование ISO С: remove()
  •       5.1.6. Символические ссылки
  •     5.2. Создание и удаление каталогов
  •     5.3. Чтение каталогов
  •       5.3.1. Базовое чтение каталогов
  •         5.3.1.1. Анализ переносимости
  •         5.3.1.2. Элементы каталогов Linux и BSD
  •       5.3.2. Функции размещения каталогов BSD
  •     5.4. Получение информации о файлах
  •       5.4.1. Типы файлов Linux
  •       5.4.2. Получение информации о файле
  •       5.4.3. Только Linux: указание файлового времени повышенной точности
  •       5.4.4. Определение типа файла
  •         5.4.4.1. Сведения об устройстве
  •         5.4.4.2. Возвращаясь к V7 cat
  •       5.4.5. Работа с символическими ссылками
  •     5.5. Смена владельца, прав доступа и времени изменения
  •       5.5.1. Смена владельца файла: chown(), fchown() и lchown()
  •       5.5.2. Изменение прав доступа: chmod() и fchmod()
  •       5.5.3. Изменение временных отметок: utime()
  •         5.5.3.1. Подделка utime(file, NULL)
  •       5.5.4. Использование fchown() и fchmod() для обеспечения безопасности
  •     5.6. Резюме
  •     Упражнения
  •   Глава 6 Общие библиотечные интерфейсы — часть 1
  •     6.1. Времена и даты
  •       6.1.1. Получение текущего времени: time() и difftime()
  •       6.1.2. Разложение времени: gmtime() и localtime()
  •       6.1.3. Форматирование даты и времени
  •         6.1.3.1. Простое форматирование времени: asctime() и ctime()
  •         6.1.3.2. Сложное форматирование времени: strftime()
  •       6.1.4. Преобразование разложенного времени в time_t
  •       6.1.5. Получение сведений о часовом поясе
  •         6.1.5.1. Системы BSD: timezone(), не timezone
  •     6.2. Функции сортировки и поиска
  •       6.2.1. Сортировка: qsort()
  •         6.2.1.1. Пример: сортировка сотрудников
  •         6.2.1.2. Пример: сортировка содержимого каталога
  •       6.2.2. Бинарный поиск: bsearch()
  •     6.3. Имена пользователей и групп
  •       6.3.1. База данных пользователей
  •       6.3.2. База данных групп
  •     6.4. Терминалы: isatty()
  •     6.5. Рекомендуемая литература
  •     6.6. Резюме
  •     Упражнения
  •   Глава 7 Соединяя все вместе: ls
  •     7.1. Опции V7 ls
  •     7.2. Код V7 ls
  •     7.3. Резюме
  •     Упражнения
  •   Глава 8 Файловые системы и обходы каталогов
  •     8.1. Монтирование и демонтирование файловых систем
  •       8.1.1. Обзор основ
  •       8.1.2. Обзор различных типов файловых систем
  •       8.1.3. Монтирование файловых систем: mount
  •       8.1.4. Демонтирование файловых систем: umount
  •     8.2. Файлы для администрирования файловой системы
  •       8.2.1. Использование опций монтирования
  •       8.2.2. Работа со смонтированными файловыми системами: getmntent()
  •     8.3. Получение сведений о файловой системе
  •       8.3.1. Стиль POSIX: statvfs() и fstatvfs()
  •       8.3.2. Стиль Linux: statfs() и fstatfs()
  •     8.4. Перемещение по иерархии файлов
  •       8.4.1. Смена каталога: chdir() и fchdir()
  •       8.4.2. Получение текущего каталога: getcwd()
  •       8.4.3. Перемещение по иерархии: nftw()
  •         8.4.3.1. Интерфейс nftw()
  •         8.4.3.2. Функция обратного вызова nftw()
  •     8.5. Обход дерева файлов: GNU du
  •     8.6. Изменение корневого каталога: chroot()
  •     8.7. Резюме
  •     Упражнения
  • Часть 2 Процессы, IPC и интернационализация
  •   Глава 9 Управление процессами и каналы
  •     9.1. Создание и управление процессами
  •       9.1.1. Создание процесса: fork()
  •         9.1.1.1. После fork(): общие и различные атрибуты
  •         9.1.1.2. Разделение дескрипторов файлов
  •         9.1.1.3. Разделение дескрипторов файлов и close()
  •       9.1.2. Идентификация процесса: getpid() и getppid()
  •       9.1.3. Установка приоритетов процесса: nice()
  •         9.1.3.1. POSIX против действительности
  •       9.1.4. Запуск новой программы: семейство exec()
  •         9.1.4.1. Системный вызов execve()
  •         9.1.4.2. Функции-оболочки: execl() и др.
  •         9.1.4.3. Имена программ и argv[0]
  •         9.1.4.4. Атрибуты, наследуемые exec()
  •       9.1.5. Завершение процесса
  •         9.1.5.1. Определение статуса завершения процесса
  •         9.1.5.2. Возвращение из main()
  •         9.1.5.3. Функции завершения
  •       9.1.6. Использование статуса завершения порожденного процесса
  •         9.1.6.1. Использование функций POSIX: wait() и waitpid()
  •         9.1.6.2. Использование функций BSD: wait3() и wait4()
  •     9.2. Группы процессов
  •       9.2.1. Обзор управления заданиями
  •       9.2.2. Идентификация группы процессов: getpgrp() и getpgid()
  •       9.2.3. Установка группы процесса: setpgid() и setpgrp()
  •     9.3. Базовое межпроцессное взаимодействие: каналы и очереди FIFO
  •       9.3.1. Каналы
  •         9.3.1.1. Создание каналов
  •         9.3.1.2. Буферирование каналов
  •       9.3.2. Очереди FIFO
  •     9.4. Управление дескрипторами файлов
  •       9.4.1. Дублирование открытых файлов: dup() и dup2()
  •       9.4.2. Создание нелинейных конвейеров: /dev/fd/XX
  •       9.4.3. Управление атрибутами файла: fcntl()
  •         9.4.3.1. Флаг close-on-exec
  •         9.4.3.2. Дублирование дескриптора файла
  •         9.4.3.3. Работа с флагами статуса файла и режимами доступа
  •         9.4.3.4. Неблокирующий ввод/вывод для каналов и FIFO
  •         9.4.3.5. Сводка fcntl()
  •     9.5. Пример: двусторонние каналы в gawk
  •     9.6. Рекомендуемая литература
  •     9.7. Резюме
  •     Упражнения
  •   Глава 10 Сигналы
  •     10.1. Введение
  •     10.2. Действия сигналов
  •     10.3. Стандартные сигналы С: signal() и raise()
  •       10.3.1. Функция signal()
  •       10.3.2. Программная отправка сигналов: raise()
  •     10.4. Обработчики сигналов в действии
  •       10.4.1. Традиционные системы
  •       10.4.2. BSD и GNU/Linux
  •       10.4.3. Игнорирование сигналов
  •       10.4.4. Системные вызовы, допускающие повторный запуск
  •         10.4.4.1. Пример: GNU Coreutils safe_read() и safe_write()
  •         10.4.4.2. Только GLIBC: TEMP_FAILURE_RETRY()
  •       10.4.5. Состояния гонок и sig_atomic_t (ISO C)
  •       10.4.6. Дополнительные предостережения
  •       10.4.7. Наша история до настоящего времени, эпизод 1
  •     10.5. API сигналов System V Release 3: sigset() и др.
  •     10.6. Сигналы POSIX
  •       10.6.1. Обнажение проблемы
  •       10.6.2. Наборы сигналов: sigset_t и связанные функции
  •       10.6.3. Управление маской сигналов: sigprocmask() и др.
  •       10.6.4. Перехват сигналов: sigaction()
  •       10.6.5. Извлечение ожидающих сигналов: sigpending()
  •       10.6.6. Создание возможности для прерывания функций: siginterrupt()
  •       10.6.7. Передача сигналов: kill() и killpg()
  •       href=#t235> 10.6.8. Наша история до настоящего времени, эпизод II
  •     10.7. Сигналы для межпроцессного взаимодействия
  •     10.8. Важные сигналы специального назначения
  •       10.8.1. Сигнальные часы: sleep(), alarm() и SIGALARM
  •         10.8.1.1. Труднее, но с большим контролем: alarm() и SIGALARM
  •         10.8.1.2. Простой и легкий: sleep()
  •       10.8.2. Сигналы, управляющие заданиями
  •       10.8.3. Родительский надзор: три различные стратегии
  •         10.8.3.1. Плохие родители: полное игнорирование потомков
  •         10.8.3.2. Снисходительные родители: минимальный надзор
  •         10.8.3.3. Строгий родительский контроль
  •     10.9. Сигналы, передающиеся через fork() и exec()
  •     10.10. Резюме
  •     Упражнения
  •   Глава 11 Права доступа и ID пользователей и групп
  •     11.1. Проверка прав доступа
  •       11.1.1. Действительные и эффективные ID
  •       11.1.2. Биты Setuid и Setgid
  •     11.2. Получение ID пользователя и группы
  •     11.3. Проверка для действительного пользователя: access()
  •     11.4. Проверка для эффективного пользователя: euidaccess() (GLIBC)
  •     11.5. Установка дополнительных битов доступа для каталогов
  •       11.5.1. Группа по умолчанию для новых файлов и каталогов
  •       11.5.2. Каталоги и «липкий» бит
  •     11.6. Установка действительных и эффективных ID
  •       11.6.1. Изменение набора групп
  •       11.6.2. Изменение действительного и эффективного ID
  •       11.6.3. Использование битов setuid и setgid
  •     11.7. Работа со всеми тремя ID: getresuid() и setresuid() (Linux)
  •     11.8. Пересечение минного поля безопасности: setuid root
  •     11.9. Рекомендуемая литература
  •     11.10. Резюме
  •     Упражнения
  •   Глава 12 Общие библиотечные интерфейсы — часть 2
  •     12.1. Операторы проверки: assert()
  •     12.2. Низкоуровневая память: функции memXXX()
  •       12.2.1. Заполнение памяти: memset()
  •       12.2.2. Копирование памяти: memcpy(), memmove() и memccpy()
  •       12.2.3. Сравнение блоков памяти: memcmp()
  •       12.2.4. Поиск байта с данным значением: memchr()
  •     12.3. Временные файлы
  •       12.3.1. Создание временных имен файлов (плохо)
  •       12.3.2. Создание и открывание временных файлов (хорошо)
  •       12.3.3. Использование переменной окружения TMPDIR
  •     12.4. Совершение самоубийства: abort()
  •     12.5. Нелокальные переходы
  •       12.5.1. Использование стандартных функций: setjmp() и longjmp()
  •       12.5.2. Обработка масок сигналов: sigsetjmp() и siglongjmp()
  •       12.5.3. Важные предостережения
  •     12.6. Псевдослучайные числа
  •       12.6.1. Стандартный С: rand() и srand()
  •       12.6.2. Функции POSIX: random() и srandom()
  •       12.6.3. Особые файлы /dev/random и /dev/urandom
  •     12.7. Расширения метасимволов
  •       12.7.1. Простое сопоставление с шаблоном: fnmatch()
  •       12.7.2. Раскрытие имени файла: glob() и globfree()
  •       12.7.3. Разворачивание слов оболочкой: wordexp() и wordfree()
  •     12.8. Регулярные выражения
  •     12.9. Рекомендуемая литература
  •     12.10. Резюме
  •     Упражнения
  •   Глава 13 Интернационализация и локализация
  •     13.1. Введение
  •     13.2. Локали и библиотека С
  •       13.2.1. Категории локалей и переменные окружения
  •       13.2.2. Установка локали: setlocale()
  •       13.2.3. Сравнение строк: strcoll() и strxfrm()
  •       13.2.4. Числовое и денежное низкоуровневое форматирование: localeconv()
  •       13.2.5. Высокоуровневое числовое и денежное форматирование: strfmon() и printf()
  •       13.2.6. Пример: форматирование числовых значений в gawk
  •       13.2.7. Форматирование значений даты и времени: ctime() и strftime()
  •       13.2.8. Другие данные локали: nl_langinfo()
  •     13.3. Динамический перевод сообщений программ
  •       13.3.1. Установка текстового домена: textdomain()
  •       13.3.2. Перевод сообщений: gettext()
  •       13.3.3. Работа с множественными числами: ngettext()
  •       13.3.4. Упрощение использования gettext()
  •         13.3.4.1. Переносимые программы: "gettext.h"
  •         13.3.4.2. Только GLIBC: <libintl.h>
  •       13.3.5. Перестановка порядка слов с помощью printf()
  •       13.3.6. Тестирование переводов в персональном каталоге
  •       13.3.7. Подготовка интернационализированных программ
  •       13.3.8. Создание переводов
  •     13.4. Не могли бы вы произнести это для меня по буквам?
  •       13.4.1. Широкие символы
  •       13.4.2. Представления многобайтных символов
  •       13.4.3. Языки
  •       13.4.4. Заключение
  •     13.5. Рекомендуемая литература
  •     13.6. Резюме
  •     Упражнения
  •   Глава 14 Расширенные интерфейсы
  •     14.1. Выделение выровненной памяти: posix_memalign() и memalign()
  •     14.2. Блокировка файлов
  •       14.2.1. Концепции блокировки файлов
  •       14.2.2. Блокировка POSIX: fcntl() и lockf()
  •         14.2.2.1. Описание блокировки
  •         14.2.2.2. Установка и снятие блокировок
  •         14.2.2.3. Предостережения по поводу блокировок
  •       14.2.3. Блокирование BSD: flock()
  •       14.2.4. Обязательная блокировка
  •     14.3. Более точное время
  •       14.3.1. Время в микросекундах: gettimeofday()
  •       14.3.2. Файловое время в микросекундах: utimes()
  •       14.3.3. Интервальные таймеры: setitimer() и getitimer()
  •       14.3.4. Более точные паузы: nanosleep()
  •     14.4. Расширенный поиск с помощью двоичных деревьев
  •       14.4.1. Введение в двоичные деревья
  •       14.4.2. Функции управления деревьями
  •       14.4.3. Ввод элемента в дерево: tsearch()
  •       14.4.4. Поиск по дереву и использование возвращенного указателя: tfind() и tsearch()
  •       14.4.5. Обход дерева: twalk()
  •       14.4.6. Удаление вершины дерева и удаление дерева: tdelete() и tdestroy()
  •     14.5. Резюме
  •     Упражнения
  • Часть 3 Отладка и заключительный проект
  •   Глава 15 Отладка
  •     15.1. Сначала главное
  •     15.2. Компиляция для отладки
  •     15.3. Основы GDB
  •       15.3.1. Запуск GDB
  •       15.3.2. Установка контрольных точек, пошаговое выполнение и отслеживаемые точки
  •     15.4. Программирование для отладки
  •       15.4.1. Код отладки времени компилирования
  •         15.4.1.1. Использование отладочных макросов
  •         15.4.1.2. По возможности избегайте макросов с выражениями
  •         15.4.1.3. При необходимости переставляйте код
  •         15.4.1.4. Используйте вспомогательные функции отладки
  •         15.4.1.5. По возможности избегайте объединений
  •       15.4.2. Отлаживаемый код времени исполнения
  •         15.4.2.1. Добавляйте отладочные опции и переменные
  •         15.4.2.2. Используйте специальные переменные окружения
  •         15.4.2.3. Добавьте код журналирования
  •         15.4.2.4. Файлы отладки времени исполнения
  •         15.4.2.5. Добавьте специальные ловушки для контрольных точек
  •     15.5. Отладочные инструменты
  •       15.5.1. Библиотека dbug — усовершенствованный printf()
  •       15.5.2. Отладчики выделения памяти
  •         15.5.2.1. GNU/Linux mtrace
  •         15.5.2.2. Electric Fence
  •         15.5.2.3. Отладка Malloc: dmalloc
  •         15.5.2.4. Valgrind: многосторонний инструмент
  •         15.5.2.5. Другие отладчики malloc
  •       15.5.3. Современная lint
  •     15.6. Тестирование программ
  •     15.7. Правила отладки
  •     15.8. Рекомендуемая литература
  •     15.9. Резюме
  •     Упражнения
  •   Глава 16 Проект, связывающий все воедино
  •     16.1. Описание проекта
  •     16.2. Рекомендуемая литература
  • Часть 4 Приложения
  •   Приложение А Научитесь программированию за десять лет
  •     Почему каждый в такой спешке?
  •     Научитесь программированию за десять лет
  •     Ссылки
  •     Ответы
  •     Сноски
  •   Приложение В Лицензия Caldera для старой Unix[194]
  •   Приложение С Общедоступная лицензия GNU[195]
  •     Как применить эти условия договора к своим новым программам
  •     Пример использования
  • *** Примечания ***