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

Роббинс Арнольд

В книге рассмотрены вопросы, связанные с программированием под Linux: файловый ввод/вывод, метаданные файлов, основы управления памятью, процессы и сигналы, пользователи и группы, вопросы интернационализации и локализации, сортировка, поиск и многие другие. Много внимания уделено средствам отладки, доступным под GNU Linux. Все темы иллюстрируются примерами кода, взятого из V7 UNIX и GNU. Эта книга может быть полезна любому, кто интересуется программированием под Linux.

 

Предисловие

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

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

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

Аудитория

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

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

Вы должны понимать базовые концепции стандартного ввода, стандартного вывода и стандартной ошибки, а также знать тот факт, что все программы на С получают массив символьных строк, представляющих вызываемые опции и аргументы. Вы должны также быть знакомы с основными инструментами командной строки, такими, как cd, cp, date, ln, ls, man (и info, если он у вас имеется), 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 и часто имеют также дополнительные, внешне не связанные опции (подобно выделению вывода).

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

Вот когда закон Хоара вдохновил нас на рассмотрение в качестве примера кода оригинальных программ 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 и в ISO. (PDF-версия стандарта С вполне доступна.)

Стандарт POSIX можно заказать в The Open Group. Исследуя в каталоге их изданий элементы, перечисленные а «Спецификациях 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, является «свобода обучения». Программы GNU предназначены для обеспечения большого собрания хорошо написанных программ, которые программисты среднего уровня могут использовать а качестве источника для своего обучения.

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

Мы считаем, что программное обеспечение GNU лучше, поскольку оно свободно (в смысле «свободы», а не «бесплатного пива»). Но признается также, что программное обеспечение 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, «Проект, связывающий все воедино»,

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

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

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

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

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

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

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

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

Соглашения об обозначениях

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

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

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

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

foo

bar

baz

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

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

Где получить исходные коды 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. Этот код можно загрузить с их веб-сайта.

Интересно отметить, что код 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 .

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

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 сделали рисунки, макеты страниц и предметный указатель; работать с ними было одно удовольствие.

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

 

Часть 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 — сменить владельца).

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

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

Unix и Linux поддерживают понятие суперпользователя (superuser): это пользователь с особыми привилегиями. Этот пользователь известен как root и имеет UID, равный 0. root позволено делать все; никаких проверок, все двери открыты, все ящики отперты. (Это может иметь важные последствия для безопасности, которых мы будем касаться по всей книге, но не будем освещать исчерпывающе.) Поэтому, даже если файл имеет режим ----------, 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 было объединение файлового ввода- вывода и ввода-вывода от устройств. Устройства выглядят в файловой системе как файлы, для доступа к ним используются обычные права доступа, а для их открытия, чтения, записи и закрытия используются те же самые системные вызовы ввода-вывода. Вся «магия», заставляющая устройства выглядеть подобно файлам, скрыта в ядре. Это просто другой аспект движущего принципа простоты в действии, мы можем выразить это как никаких частных случаев для кода пользователя.

В повседневной практике, в частности, на уровне оболочки, часто появляются два устройства: /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

 

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

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

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

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

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

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

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

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

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

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

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

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

• установки для размещения сигналов (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 г. формализовал определения языка, включая функции библиотеки С (такие, как 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 г. продолжает допускать объявления и определения в оригинальном стиле. Однако, правило «неявного int» было убрано; функции должны иметь возвращаемый тип, а все параметры должны быть объявлены.

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

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

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

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

 

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

 

Что делает программу GNU программой GNU? Что делает программное обеспечение 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 С. Но поскольку ядро еще не завершено, и пользователи используют инструменты 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, мы чувствуем, что при модификации некоторых других программ, придерживание уже использованного стиля кода является исключительно важным. Последовательность в стиле кода более важна, чем сам стиль, который вы выбираете. 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.

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

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

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

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

Наконец, мы цитируем главу 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.

Это «библия» С, охватывающая версию стандарта С 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»), первоначально написанную в августе 1998 г.

 

Глава 2

Аргументы, опции и переменные окружения

 

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

 

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

 

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

$ ls main.с opts.с process.с

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

Второе определение более неформальное: аргументами являются все слова командной строки, за исключением имени команды. По умолчанию, оболочки 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, завершающий символ новой строки опускается. (Это используется для приглашений из сценариев оболочки.) Вот код:

1  #include

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

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. Мы решили оставить использующий это слово код, как есть, но вы должны знать, что оно больше не имеет реального применения.

 

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 /*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 /* 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 определена в ; она выглядит следующим образом:

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). Исходные файлы getopt.h, getopt.с и getopt1.c. Они лицензированы на условиях меньшей общедоступной лицензии (Lesser General Public License) GNU, которая позволяет включать библиотечные функции даже в патентованные программы. Вы должны включить в свою программу копию файла COPYING.LIB наряду с файлами getopt.h, getopt.с и getopt1.с.

Включите исходные файлы в свой дистрибутив и откомпилируйте их с другими исходными файлами. В исходном коде, вызывающем getopt_long(), используйте '#include ', а не '#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

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

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, отображает

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

Об ошибках сообщайте в . */

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

$ 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

81  #include

82  #include

83  #include

84  #include

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),

 • Argp,

 • Argv,

 • Autoopts,

 • GNU Gengetopt,

 • Opt,

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

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

 

Глава 3

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

 

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

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

 

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

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

Код

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

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

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

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

Глобальные и статически выделенные данные, которые по умолчанию инициализированы нулями, хранятся в области процесса, который называют областью BSS. У каждого процесса, в котором запущена одна и та же программа, своя область 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 удаляет символы из объектного файла. Для большой программы это может сохранить значительное дисковое пространство ценой невозможности отладки дампа ядра, если таковой появится (На современных системах об этом не стоит беспокоиться, не используйте strip.) Даже после удаления символов файл все еще больше, чем загруженный в память образ, поскольку формат объектного файла содержат дополнительные данные о программе, такие, как использованные разделяемые библиотеки, если они есть.

Наконец, упомянем потоки (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 /* 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; /* какой у нас индекс? */

}

Заголовочный файл объявляет множество стандартных библиотечных функций С и типов (таких, как 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().

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

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, очевидно, библиотека на этих системах автоматически осуществляет это преобразование. Это верно также для других не-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, и код выходит из цикла.

С другой стороны, если число нечетно, строка содержит четное число пар обратных слешей (представляющих символы \\, как в С), и конечную комбинацию символов обратного слеша и конца строки. В этом случае, если в буфере остались по крайней мере 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) не возвращается.

 

3.2.1.9. Только GLIBC: чтение целых строк:

getline()

и

getdelim()

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

#define _GNU_SOURCE 1 /* GLIBC */

#include

#include /* для 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 нужен файл . (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

#include

/* 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

/* 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 /* XSI */

char *strdup(const char *str); /* Копировать str */

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

 

3.2.3. Системные вызовы:

brk()

и

sbrk()

Четыре функции, которые мы рассмотрели (malloc(), calloc(), realloc() и free()) являются стандартными, переносимыми функциями для управления динамической памятью.

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

#include /* Обычный */

#include /* Необходим для систем 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 /* Обычный */

void *alloca(size_t size);

Функция alloca() выделяет size байтов из стека. Хорошо, что выделенная память исчезает после возвращения из функции. Нет необходимости явным образом освобождать память, поскольку это осуществляется автоматически, как в случае с локальными переменными.

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

• Функция не является стандартной; она не включена ни в какой стандарт, ни в ISO, ни в С или POSIX.

• Функция не переносима. Хотя она существует на многих системах Unix и GNU/Linux, она не существует на не-Unix системах. Это проблема, поскольку код часто должен быть многоплатформенным, выходя за пределы просто Linux и Unix.

• На некоторых системах alloca() невозможно даже реализовать. Весь мир не является ни процессором Intel x86, ни GCC.

• Цитируя справку (добавлено выделение): «Функция 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

7  #include /* для определения ptrdiff_t в GLIBC */

8  #include

9  #include /* лишь для демонстрации */

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 /* POSIX */

#include /* для mode_t */

#include     /* для flags для open() */

#include    /* для 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 /* для fprintf(), stderr, BUFSIZ */

7  #include /* объявление errno */

8  #include /* для flags для open() */

9  #include /* объявление strerror() */

10 #include /* для ssize_t */

11 #include

12 #include /* для 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 и предопределенные значения ошибок определены в файле заголовка .

#include /* 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 /* ISO С */

void perror(const char *s);

Функция perror() выводит предоставленную программой строку, за которой следует двоеточие, а затем строка, описывающая значение errno:

if (some_system_call(param1, param2) < 0) {

 perror("system call failed");

 return 1;

}

Мы предпочитаем функцию strerror(), которая принимает параметр со значением ошибки и возвращает указатель на строку с описанием ошибки:

#include /* 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 /* Обычный */

int getdtablesize(void);

Следующая небольшая программа выводит результат работы этой функции:

/* ch04-maxfds.с --- Демонстрация getdtablesize(). */

#include /* для fprintf(), stderr, BUFSIZ */

#include /* для 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 /* POSIX */

#include

#include

#include

int open(const char *pathname, int flags, mode_t mode);

Три аргумента следующие:

const char *pathname

Строка С, представляющая имя открываемого файла.

int flags

Поразрядное ИЛИ с одной или более констант, определенных в . Вскоре мы их рассмотрим.

mode_t mode

Режимы доступа для создаваемого файла. Это обсуждается далее в главе, см. раздел 4.6 «Создание файлов». При открытии существующего файла опустите этот параметр.

Возвращаемое 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 /* 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* из , такие, как stdin, stdout и stderr, построены поверх основанных на дескрипторах файлов системных вызовах.

Иногда полезно получить непосредственный доступ к дескриптору файла, связанному с указателем файла , если вам нужно сделать что-либо, не определенное стандартом С ISO. Функция fileno() возвращает лежащий в основе дескриптор файла:

#include /* 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 /* POSIX */

#include

#include

#include

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; эта константа определена В как «оптимальный» размер блока для ввода/вывода. Хотя значение 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. Она начинается с проверки опций, cat V7 принимает единственную опцию, -u, для осуществления небуферированного вывода.

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

1  /*

2   * Объединение файлов.

3   */

4

5  #include

6  #include

7  #include

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 /* для off_t; POSIX */

#include /* объявления 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 /* для fprintf(), stderr, BUFSIZ */

4  #include /* объявление errno */

5  #include /* для flags для open() */

6  #include /* объявление strerror() */

7  #include /* для ssize_t */

8  #include /* для off_t, etc. */

9  #include   /* для 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 блоков! Отсутствующие блоки в файле являются дырами. Это показано на рис. 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 для одной или более символических имен из , описанных в табл. 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 /* POSIX */

#include 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() создает новые файлы. Он объявлен следующим образом:

#include /* POSIX */

#include

#include

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).

Для большинства приложений вероятность того, что данные в буферном кэше могут быть нечаянно потеряны, довольно низка. Однако, для некоторых приложений любой такой шанс неприемлем. Поэтому в системе 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_ x SYNC , но с последующим использованием одного из следующих двух системных вызовов в любой момент, когда это необходимо для безопасного перемещения данных на физический носитель:

#include

int fsync(int fd); /* POSIX FSC */

int fdatasync(int fd); /* POSIX SIO */

Системный вызов fdatasync() подобен O_DSYNC: он форсирует запись данных на конечное физическое устройство. Системный вызов fsync() подобен O_SYNC, форсируя запись на физическое устройство не только данных файла, но и вспомогательных данных. Вызов fsync() более переносим; он существовал в мире Unix в течение более продолжительного времени, и вероятность его наличия среди широкого ряда систем больше.

Можно использовать эти вызовы с указателями файлов , вызвав сначала 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

#include

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 как '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 /* 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 работали таким способом. Однако, при таком способе переименование файла не является атомарным; т.е. оно не осуществляется посредством одной непрерываемой операции. И на сильно загруженной системе злонамеренный пользователь мог бы воспользоваться условиями состояния гонки, разрушая операцию переименования и подменяя оригинальный файл другим.

По этой причине 4.2 BSD ввело системный вызов rename():

#include /* ISO С */

int rename(const char *oldpath, const char *newpath);

На системах Linux операция переименования является атомарной; справочная страница утверждает:

Если newpath уже существует, он будет атомарно замещен .., таким образом, что при попытке другого процесса получить доступ к newpath он никогда не обнаружит его отсутствующим.

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

Как и в случае с другими системными вызовами, возвращенный 0 означает успех, а (-1) означает ошибку.

 

5.1.5. Удаление файла

 

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

Системный вызов называется unlink():

#include /* POSIX */

int unlink(const char *pathname);

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

 

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 /* 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 /* 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 /* POSIX */

#include

int mkdir(const char *pathname, mode_t mode);

#include /* 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

5  #include

6  #include

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, строки 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.2 BSD представило новый формат файловой системы, который допускал длинные имена файлов и обеспечивал лучшую производительность, были также представлены несколько новых функций для абстрагирования чтения каталогов. Этот набор функций можно использовать независимо от того, какова лежащая в основе файловая система и как организованы каталоги. Основная ее часть стандартизована 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 определен в .) Расширение XSI POSIX предусматривает поле номера индекса d_ino.

На практике, поскольку имена файлов могут быть различной длины, a NAME_MAX обычно довольно велико (подобно 255), struct dirent содержит дополнительные члены, которые помогают вести на диске учет элементов каталогов с переменными длинами. Эти дополнительные члены не существенны для обычного кода.

Следующие функции предоставляют интерфейс чтения каталогов:

#include /* POSIX */

#include

DIR *opendir(const char *name);   /* Открыть каталог для чтения */

struct dirent *readdir(DIR *dir); /* Вернуть struct dirent за раз */

int closedir(DIR *dir);           /* Закрыть открытый каталог */

void rewinddir(DIR *dirp);        /* Вернуться в начало каталога */

Тип DIR является аналогом типа FILE в . Это непрозрачный тип, что означает, что код приложения не должен знать, что находится внутри него; его содержимое предназначено для использования другими процедурами каталогов. Если opendir() возвращает NULL, именованный каталог не может быть открыт для чтения, а errno содержит код ошибки.

Открыв переменную DIR*, можно использовать ее для получения указателя на struct dirent, представляющего следующий элемент каталога. readdir() возвращает NULL, если достигнут конец каталога или произошла ошибка.

Наконец, closedir() является аналогичной функции fclose() в ; она закрывает открытую переменную DIR*. Чтобы начать с начала каталога, можно использовать функцию rewinddir().

Имея в распоряжении (или по крайней мере в библиотеке С) эти функции, мы можем написать небольшую программу catdir, которая «отображает» содержимое каталога. Такая программа представлена в ch05-catdir.с:

1  /* ch05-catdir.с - Демонстрация opendir(), readdir(), closedir(). */

2

3  #include /* для printf() и т.д. */

4  #include /* для errno */

5  #include /* для системных типов */

6  #include /* для функций каталога */

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, и '.' и '..' могут быть в середине каталога или даже вовсе не присутствовать.

Во-вторых, стандарт 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 /* XSI */

/* Предупреждение: POSIX XSI использует для обеих функций long, а не off_t */

off_t telldir(DIR *dir);              /* Вернуть текущее положение */

void seekdir(DIR *dir, off_t offset); /* Переместиться в данное положение */

Эти процедуры подобны функциям ftell() и fseek() и . Они возвращают текущее положение в каталоге и устанавливают текущее положение в ранее полученное значение соответственно.

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

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

 

5.4. Получение информации о файлах

 

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

 

5.4.1. Типы файлов Linux

Linux (и Unix) поддерживает следующие различные типы файлов:

Обычные файлы

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

Каталоги

Специальные файлы для связывания имен файлов с индексами. В листинге 'ls -l' они обозначаются первым символом d поля прав доступа.

Символические ссылки

Как описано ранее в главе. В листинге 'ls -l' обозначаются первым символом l (буква «эль», не цифра 1) поля прав доступа.

Устройства

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

Блочные устройства

Устройства, ввод/вывод которых осуществляется порциями некоторого фиксированного размера физической записи, такие, как дисковые и ленточные приводы. Доступ к таким устройствам осуществляется через буферный кэш ядра. В листинге 'ls -l' они обозначаются первым символом b поля прав доступа.

Символьные устройства

Известны также как непосредственные (raw) устройства. Первоначально символьными устройствами были те, в которых ввод/вывод осуществлялся по несколько байтов за раз, как в терминалах. Однако, символьное устройство используется также для непосредственного ввода/вывода на блочные устройства, такие, как ленты и диски, минуя буферный кэш. В листинге 'ls -l' они отображаются первым символом с поля прав доступа.

Именованные каналы (named pipes)

Известны также файлы FIFO («first-in first-out» — «первым вошел, первым обслужен»). Эти специальные файлы действуют подобно конвейерам (pipes); данные, записанные в них одной программой, могут быть прочитаны другой; данные не записываются на диск и не считываются с диска. FIFO создаются с помощью команды mkfifo; они обсуждаются в разделе 9.3.2 «FIFO». В листинге 'ls -l' они отображаются первым символом p поля прав доступа.

Сокеты

Сходные по назначению с именованными каналами, они управляются системными вызовами межпроцессных взаимодействий (IPC) сокетов, и мы не будем в данной книге иметь с ними дело в других отношениях. В листинге 'ls -l' они отображаются первым символом s поля прав доступа.

 

5.4.2. Получение информации о файле

Три системных вызова возвращают информацию о файлах:

#include /* POSIX */

#include

#include

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, объявленной в . Как в случае с 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 в . Эта константа не стандартизована, но довольно широко используется в системах 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 закодированы как тип файла, так и права доступа к нему. определяет ряд макросов, которые определяют тип файла. В частности, эти макросы возвращают true или false при использовании с полем st_mode. У каждого описанного ранее типа файла есть свой макрос. Предположим, выполняется следующий код:

struct stat stbuf;

char filename[PATH_МАХ]; /* PATH_MAX из */

/* ... поместить имя файла в 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) ...

Наряду с макросами предоставляет два набора битовых масок. Один набор для проверки прав доступа, а другой - для проверки типа файла. Мы видели маски прав доступа в разделе 4.6 «Создание файлов», когда обсуждали тип mode_t и значения для open() и creat(). Битовые маски, их числовые значения для GNU/Linux и смысл приведены в табл. 5.2.

Таблица 5.2. Битовые маски POSIX для типов файлов и прав доступа в

Маска Значение Комментарий
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_IS xxx () .

 

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(), определенных в :

#include /* Обычный */

#include

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

#include

#include

#include

#include

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, давая нам уверенность, что мы в самом деле написали правильный код.

Воспроизведение вывода 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), ни один действительный номер индекса не будет ему соответствовать. То, что 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 /* 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 в */

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'; /* Составить строку С */

Данный пример для простоты представления использует буферы фиксированного размера. Реальный код мог бы использовать для выделен