Linux API. Исчерпывающее руководство

Из указанного выше подхода следует сделать одно исключение. Поскольку в некоторых средах компиляции тип данных off_t имеет размерность long long, мы приводим off_t-значения к этому типу и в соответствии с описанием из раздела 5.10 используем спецификатор %lld.

В стандарте C99 для printf() определен модификатор длины z, показывающий, что Результат следующего целочисленного преобразования соответствует типу size_t или ssize_t. Следовательно, вместо использования %ld и приведения к этим типам можно указать %zd для ssize_t и аналогично %zu для size_t. Хотя этот спецификатор доступен в glibc, нам нужно избегать его применения, поскольку он доступен не во всех реализациях UNIX.

В стандарте C99 также определен модификатор длины j, который указывает на то, что соответствующий аргумент имеет тип intmax_t (или uintmax_t) — целочисленный тип, гарантированно достаточно большой для представления целого значения любого типа. По сути, использование приведения к типу (intmax_t) и добавление спецификатора %jd должно заменить приведение к типу (long) и задание спецификатора %ld, а также стать лучшим способом вывода числовых значений типов системных данных. Первый подход справляется и со значениями long long, и с любыми расширенными целочисленными типами, такими как int128_t. Но и в данном случае нам следует избегать применения этой методики, поскольку она доступна не во всех реализациях UNIX.

3.6.3. Прочие вопросы, связанные с портированием

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

Инициализация и использование структур

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

struct sembuf {

unsigned short sem_num; /* Номер семафора */

short sem_op; /* Выполняемая операция */

short sem_flg; /* Флаги операции */

};

Хотя в SUSv3 определены такие структуры, как sembuf, важно уяснить следующее.

• Обычно порядок определения полей внутри таких структур не определен.

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

Таким образом, при использовании следующего инициализатора структуры не удастся обеспечить портируемость:

struct sembuf s = { 3, -1, SEM_UNDO };

Хотя этот инициализатор будет работать в Linux, он не станет работать в других реализациях, где поля в структуре sembuf определены в ином порядке. Чтобы инициализировать такие структуры портируемым образом, следует воспользоваться явно указанными инструкциями присваивания:

struct sembuf s;

s. sem_num = 3;

s. sem_op = -1;

s. sem_flg = SEM_UNDO;

Если применяется C99, то для написания эквивалентной инициализации можно воспользоваться новым синтаксисом:

struct sembuf s = {.sem_num = 3, sem_op = -1, sem_flg = SEM_UNDO };

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

Использование макросов, которых может не быть во всех реализациях

В некоторых случаях макрос может быть не определен во всех реализациях UNIX. Например, широкое распространение получил макрос WCOREDUMP() (проверяет, создается ли дочерним процессом файл дампа ядра), но его определение в SUSv3 отсутствует. Следовательно, этот макрос может быть не представлен в некоторых реализациях UNIX. Чтобы для обеспечения портируемости преодолеть подобные обстоятельства, можно воспользоваться директивой препроцессора языка C #ifdef:

#ifdef WCOREDUMP

/* Использовать макрос WCOREDUMP() */

#endif

Отличия в требуемых заголовочных файлах в разных реализациях

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

В некоторых функциях, кратко рассматриваемых в книге, показан конкретный заголовочный файл, сопровождаемый комментарием /* For portability */ (/* Из соображений портируемости */). Это свидетельствует о том, что данный заголовочный файл для Linux или согласно SUSv3 не требуется, но, поскольку некоторым другим (особенно старым) реализациям он может понадобиться, нам приходится включать его в портируемые программы.