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

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

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

Текущий рабочий каталог — это каталог, относительно которого отсчитываются относительные пути файлов (те, которые не начинаются с '

/

'). Это каталог, в котором

вы находитесь, когда набираете команду оболочки '

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

17

Между народный стандарт ISO/IEC 9899-1990 описывает разновидность языка С известную также как C89 или C90 — Примеч. науч. ред.

Объявление

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

.

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