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

Предисловие

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

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

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

Аудитория

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

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

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

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

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

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

Стандарты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможности и мощь: программы GNU

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

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

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

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

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

Обзор глав

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

foo

bar

baz

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

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

Где получить исходные коды Unix и GNU

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

Код Unix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код GNU

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

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

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

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

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

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

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

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

Connected to ftp.gnu.org (199.232.41.7).

220 GNU FTP server ready.

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

331 Please specify the password.

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

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

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

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

230 Login successful. Have fun.

Remote system type is UNIX.

Using binary mode to transfer files.

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

250 Directory successfully changed.

ftp> bin

200 Switching to Binary mode.

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

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

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

local: coreutils-5.0.tar.gz

remote: coreutils-5.0.tar.gz

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

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

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

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

...

226 File send OK.

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

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

221 Goodbye.

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

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

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

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

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

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

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

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

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

Примеры программ, использованные в данной книге, можно найти по адресу: http://authors.phptr.com/robbins.

Об обложке

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

- Оби-Ван Кеноби -

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

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

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

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

Благодарности

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

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

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

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

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

Nof Ayalon

ИЗРАИЛЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ ls -l progex.texi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ ls -ld /trap

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

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

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

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

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

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

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

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

#! /bin/awk -f

BEGIN {print "hello, world"}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объявление

extern int myfunc(struct my_struct *a,

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

Определение

int myfunc(struct my_struct *a,

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

 ...

}

...

struct my_struct s, t;

int j;

...

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

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

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

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

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

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

extern int myfunc();

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

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

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

struct my_struct *а, *b;

double с;

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

{

 ...

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.7. Резюме

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

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

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

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

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

Упражнения

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

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

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

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

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

$ ls main.с opts.с process.с

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

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

$ echo here are lots of spaces

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

$ echo "here are lots of spaces"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{                                 {

...                                ...

}                                 }

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

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

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

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

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

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

1  #include <stdio.h>

2

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

4  int argc;

5  char *argv[];

6  {

7   register int i, nflg;

8

9   nflg = 0;

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

11   nflg++;

12   argc--;

13   argv++;

14  }

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

16   fputs(argv[i], stdout);

17   if (i < argc-1)

18   putchar(' ');

19  }

20  if (nflg == 0)

21   putchar('\n');

22  exit(0);

23 }

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

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

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

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

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

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

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

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

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

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

extern char *optarg;

extern int optind, opterr, optopt;

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

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

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

char *b_opt_arg;

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

 switch (oc) {

 case 'a':

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

  break;

 case 'b':

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

  b_opt_arg = optarg;

  break;

 case ':':

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

 case '?':

 default:

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

 }

}

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

char *optarg

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

int optind

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

int opterr

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

int optopt

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

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

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

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

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

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

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

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

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

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

char *b_opt_arg;

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

 switch (oc) {

 case 'a':

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

  break;

 case 'b':

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

  b_opt_arg = optarg;

  break;

 case ':':

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

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

   argv[0], optopt);

  break;

 case '?':

 default:

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

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

   argv[0], optopt);

  break;

 }

}

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

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

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

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

optstring[0] == '+'

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

optstring[0] == '-'

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

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

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

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

...

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

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

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

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

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

 const char *optstring,

 const struct option *longopts, int *longindex);

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

 const char *optstring,

 const struct option *longopts, int *longindex);

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

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

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

struct option {

 const char *name;

 int has_arg;

 int *flag;

 int val;

};

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

const char *name

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

int has_arg

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

int *flag

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

int val

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

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

Макроподстановка	Числовое значение	Смысл
no_argument	0	Опция не принимает аргумент
required_argument	1	Опции требуется аргумент
optional_argument	2	Аргумент опции является необязательным

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

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

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

 switch (с) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'v':

  do_verbose = 1;

  break;

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

 }

}

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

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

char *my_file;

struct option longopts[] = {

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

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

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

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

 { 0, 0, 0, 0 }

};

while ((с =

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

 switch (c) {

 case 'f':

  myfile = optarg;

  break;

 case 0:

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

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

  break;

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

 }

}

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

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

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

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

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

while ((с =

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

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

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

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

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

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

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

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

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

struct option longopts[] = {

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

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

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

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

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

 { 0, 0, 0, 0 }

};

...

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

 switch (c) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'u':

  if (optarg != NULL)

   user = optarg;

  else

   user = "root";

  break;

 case 'v':

  do_verbose = 1;

  break;

 case 0:

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

  break;

#if 0

 case 1:

  /*

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

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

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

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

   */

  break;

#endif

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

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

   argv[0], optopt);

  break;

 case '?':

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

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

   argv[0], optopt);

  break;

 }

}

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

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

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

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

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

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

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

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

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

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

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

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

text data bss dec hex filename

0 0 0 0 0 getopt.о

0 0 0 0 0 getopt1.о

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

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

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

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

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

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

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

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

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

#include <stdlib.h>

char *getenv(const char *name);

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

   окружения */

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

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

           int overwrite);

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

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

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

                                    окружения */

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

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

char *pathval;

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

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

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

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

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

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

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

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

}

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

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

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

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

}

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

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

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

unsetenv("PATH");

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

if (clearenv() != 0) {

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

}

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

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

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

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

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

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

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

#include <stdio.h>

extern char **environ;

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

 int i;

 if (environ != NULL)

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

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

 return 0;

}

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

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

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

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

 ...

}

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

2.4.3. GNU env

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

$ env --help

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

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

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

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

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

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

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

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

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

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

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

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

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

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

80  #include <config.h>

81  #include <stdio.h>

82  #include <getopt.h>

83  #include <sys/types.h>

84  #include <getopt.h>

85

86  #include "system.h"

87  #include "error.h"

88  #include "closeout.h"

89

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

91  #define PROGRAM_NAME "env"

92

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

94

95  int putenv();

96

97  extern char **environ;

98

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

100 char *program_name;

101

102 static struct option const longopts[] =

103  {

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

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

106  {GETOPT_HELP_OPTION_DECL},

107  {GETOPT_VERSION_OPTION_DECL},

108  {NULL, 0, NULL, 0}

109 };

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

111 void

112 usage(int status)

113 {

114  if (status '= 0)

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

116    program_name);

117  else

118  {

119   printf (_("\

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

121    program_name);

122   fputs (_("\

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

124    \n\

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

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

127    "), stdout);

128   fputs(HELP_OPTION_DESCRIPTION, stdout);

129   fputs(VERSION_OPTION_DESCRIPTION, stdout);

130   fputs(_("\

131    \n\

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

133    environment.\n"), stdout);

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

135  }

136  exit(status);

137 }

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

139 int

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

141 {

142  char *dummy_environ[1];

143  int optc;

144  int ignore_environment = 0;

145

146  program_name = argv[0];

147  setlocale(LC_ALL, "");

148  bindtextdomain(PACKAGE, LOCALEDIR);

149  textdomain(PACKAGE);

150

151  atexit(close_stdout);

152

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

154  {

155   switch (optc)

156   {

157   case 0:

158    break;

159   case 'i':

160    ignore_environment = 1;

161    break;

162   case 'u':

163    break;

164   case_GETOPT_HELP_CHAR;

165   case_GETOPT_VERSION_CHAR(PROGRAM_NAME, AUTHORS);

166   default:

167    usage(2);

168   }

169  }

170

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

172   ignore_environment = 1;

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

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

   --version. */

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

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

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

*/

enum {

 GETOPT_HELP_CHAR = (CHAR_MIN — 2),

 GETOPT_VERSION_CHAR = (CHAR_MIN - 3)

};

#define GETOPT_HELP_OPTION_DECL \

 "help", no_argument, 0, GETOPT_HELP_CHAR

#define GETOPT_VERSION_OPTION_DECL \

 "version", no_argument, 0, GETOPT_VERSION_CHAR

#define case_GETOPT_HELP_CHAR \

 case GETOPT_HELP_CHAR: \

  usage(EXIT_SUCCESS); \

  break;

#define case_GETOPT_VERSION_CHAR(Program_name, Authors) \

 case GETOPT_VERSION_CHAR: \

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

  exit(EXIT_SUCCESS); \

  break;

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

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

174 environ = dummy_environ;

175 environ[0] = NULL;

176

177 if (!ignore_environment)

178  for (; *envp; envp++)

179   putenv(*envp);

180

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

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

183  if (optc == 'u')

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

185

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

187  ++optind;

188

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

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

190 putenv(argv[optind++]);

191

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

193 if (optind == argc)

194 {

195  while (*environ)

196   puts (*environ++);

197  exit(EXIT_SUCCESS);

198 }

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

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

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

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

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

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

201

202  {

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

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

205   exit(exit_status);

206  }

207 }

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

2.5. Резюме

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

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

Упражнения

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

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

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

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

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

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

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

 • Argp^[32],

 • Argv^[33],

 • Autoopts^[34],

 • GNU Gengetopt^[35],

 • Opt^[36],

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

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

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

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

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

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

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

Код

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

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

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

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

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

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

Куча (heap)

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

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

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

Стек

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

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

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

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

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

Память программы	Сегмент адресного пространства	Секция исполняемого файла
Код	Text	Text
Инициализированные данные	Data	Data
BSS	Data	BSS
Куча	Data
Стек	Stack

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

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

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

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

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

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr

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

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

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

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

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr

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

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

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

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

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

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

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

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

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

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

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

void *calloc(size_t nmemb, size_t size);

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

void *malloc(size_t size);

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

void free(void *ptr);

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

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

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

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

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

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

#define MAXBUF ...

char *p;

char buf[MAXBUF];

ptrdiff_t where;

p = buf;

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

 ...

 p += something;

 ...

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

}

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

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

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

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

 int x, y, z;

} *coordinates;

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

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

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

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

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

if (coordinates == NULL) {

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

}

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

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

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