Выбрать главу

Дополнительные интерфейсы и особенности поведения, требуемые для XSI-соответствия, обобщенно называются XSI-расширением. В их число входит поддержка потоков, функций mmap() и munmap(), API dlopen, ограничений ресурсов, псевдотерминалов, System V IPC, API syslog, функции poll(), учетных записей пользователей.

В дальнейшем, когда речь пойдет о SUSv3-соответствии, мы будем иметь в виду XSI-соответствие.

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

Неопределенные и слабо определенные интерфейсы

Временами вам будут попадаться ссылки на неопределенные или слабо определенные в SUSv3 интерфейсы.

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

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

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

Средства с пометкой LEGACY

Иногда какое-то средство в SUSv3 имеет пометку LEGACY. Она означает, что это средство оставлено для сохранения совместимости со старыми приложениями, а в новых приложениях его лучше не использовать. Во многих случаях существуют другие API, предоставляющие эквивалентные функциональные возможности.

1.3.5. SUSv4 и POSIX.1-2008

В 2008 году Austin Group завершила пересмотр объединенной спецификации POSIX.1 и Single UNIX. Как и предшествующая версия стандарта, она состоит из основной спецификации, дополненной XSI-расширением. Эту редакцию мы будем называть SUSv4.

Изменения в SUSv4 не столь масштабные, как в SUSv3. Из наиболее существенных можно выделить следующие.

• Добавлены новые спецификации для некоторых функций. Из их числа в книге упоминаются dirfd(), fdopendir(), fexecve(), futimens(), mkdtemp(), psignal(), strsignal() и utimensat(). Другие новые функции предназначены для работы с файлами (например, openat(), рассматриваемая в разделе 18.11) и практически являются аналогами существующих функций (например, open()). Они отличаются лишь тем, что относительный путь к файлу разрешается относительно каталога, на который ссылается дескриптор открытого файла, а не относитльно текущего рабочего каталога процесса.

• Некоторые функции, указанные в SUSv3 как необязательные, становятся обязательной частью стандарта в SUSv4. Например, отдельные функции, составлявшие в SUSv3 часть XSI-расширения, в SUSv4 стали частью базового стандарта. Среди функций, ставших обязательными в SUSv4, можно назвать функции, входящие в API сигналов режима реального времени (раздел 22.8), в API POSIX-таймеров (раздел 23.6), в API dlopen (раздел 42.1) и в API POSIX-семафоров (глава 48).

• Кое-какие функции из SUSv3 в SUSv4 помечены как устаревшие. К их числу относятся asctime(), ctime(), ftw(), gettimeofday(), getitimer(), setitimer() и siginterrupt().

• Спецификации некоторых функций, помеченных в SUSv3 как устаревшие, из SUSv4 удалены. Среди них gethostbyname(), gethostbyaddr() и vfork().

• Различные особенности существующих в SUSv3 спецификаций претерпели изменения в SUSv4. Например, к списку функций, от которых требуется обеспечение безопасной обработки асинхронных сигналов, добавились дополнительные функции (см. табл. 21.1).

Далее в книге изменения в SUSv4, относящиеся к рассматриваемым вопросам, будут оговариваться специально.

1.3.6. Этапы развития стандартов UNIX

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

Ситуация с сетевыми стандартами была несколько сложнее. Действия по стандартизации в этой области начали предприниматься в конце 1980-х годов. В то время был образован комитет POSIX 1003.12 для стандартизации API сокетов, API X/Open Transport Interface (XTI) (альтернативный API программирования сетевых приложений на основе интерфейса транспортного уровня System V Transport Layer Interface) и различных API, связанных с работой в сети. Становление стандарта POSIX 1003.12 заняло несколько лет, в течение которых он был переименован в POSIX 1003.1g. Этот стандарт был одобрен в 2000 году.