Реферат: Мобильное программирование в среде ОС UNIX

Число значащих начальных символов (сверх 6) в идентификаторе с внешней связью.

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

Имеет ли значение регистр символов, входящих в идентификаторы с внешней связью.

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

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

Это касается, в основном, символов, используемых в символьных и строковых константах (например, русские буквы).

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

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

Соответствие символов входного алфавита (в символьных и строковых константах) символам алфавита времени выполнения.

В основном это касается управляющих символов. Например, символ "конец строки" (\n) в разных реализациях может быть представлен в потоках ввода-вывода различными последовательностями кодов. Надо стараться писать программу так, чтобы ее поведение не зависело от конкретного представления управляющих символов в окружении выполнения.

Число и порядок символов в целом.

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

Число и порядок следования разрядов в символах из набора символов времени выполнения.

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

Переносимой программе не следует использовать информацию этих двух пунктов.

Значение символьной константы, состоящей более, чем из одного символа.

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

Следует ли трактовать "простые" символьные объекты как знаковые или беззнаковые.

Переносимая программа не должна зависеть от того, является ли тип char знаковым или беззнаковым.

Представление и наборы значений различных целочисленных типов.

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

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

Переносимая программа не использует эту информацию.

Результаты поразрядных операций над знаковыми целыми.

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

Знак остатка целочисленного деления.

Переносимая программа не использует эту информацию.

Является ли сдвиг вправо значения знакового целочисленного типа логическим или арифметическим.

Переносимая программа не должна зависеть от вида сдвига вправо знаковых целых.

Представление и наборы значений различных типов вещественных чисел.

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

Способ округления, когда вещественное число преобразуется к более узкому вещественному числу.

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

Тип целого, которое может вместить максимальный размер массива, то есть тип size_t - тип результата операции sizeof.

Результат преобразования указателя в целое и наоборот.

Тип целого, которое может вместить разность между двумя указателями на один и тот же массив - ptrdiff_t.

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

Элемент смеси union используется как элемент другого типа.

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

Дополнение пустот и выравнивание элементов записей.

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

Считается ли "простое" целое битовое поле знаковым или беззнаковым.

Переходит ли битовое поле, не умещающееся в одном целом, в следующее.

Порядок расположения битовых полей в целом.

Может ли битовое поле пересекать физические границы ячеек памяти.

Переносимая программа не должна использовать всю эту информацию.

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

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

Максимальное число вариантов в переключателе.

Переносимая программа должна исходить из того, что число вариантов в переключателе не должно превышать 255.

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

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

Обработка имен в кавычках, относящихся к включаемым файлам.

Поведение каждой директивы #pragma.

Определение имен __DATE__ и __TIME__, когда, соответственно дата и время трансляции не может быть доступно.

Константа, получающаяся при подстановке макроопределения NULL, обозначающая пустой указатель.

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

Диагностическое сообщение и способ завершения программы, применяемый в функции assert.

Наборы символов, проверяемые в функциях isalnum, isalpha, iscntrl, islower, isprint и isupper.

Значения, выдаваемые математическими функциями при возникновении ошибок области определения.

Устанавливают ли математические функции целое выражение errno в положение ERANGE при возникновении потери значимости.

Набор сигналов для функции signal.

Семантика каждого сигнала, распознаваемого библиотечной функцией signal.

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

Восстанавливается ли стандартная обработка, если при обработке сигнала функцией, указанной при вызове функции signal, возникает сигнал SIGILL.

Нужно ли заканчивать последнюю строку текстового потока символом "конец строки".

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

Количество символов NULL, которые дописываются к двоичному потоку.

Характеристики буферизации файлов.

Существует ли файл нулевой длины.

Правила образования правильных имен файлов.

Может ли один файл открываться много раз.

Результат выполнения функции remove над открытым файлом.

Эффект работы функции rename, если файл с новым именем существовал ранее.

Выходная строка, получающаяся при работе преобразования %p в функции fprintf.

Входная строка, поступающая для преобразования %p в функции fscanf.

Интерпретация символа ^, который есть ни первый, ни последний символ в списке сканирования в преобразовании %[ в функции fscanf.

Значение, которое получает errno от функций fgetpos и ftell в случае неудачи.

Сообщения, выдаваемые функцией perror.

Поведение функций calloc, malloc и realloc в случае, если размер запрошенной памяти равен нулю.

Поведение функции abort по отношению к открытым и временным файлам.

Статус, возвращаемый функцией exit, если значение фактического параметра не равно нулю, или значениям макроимен EXIT_SUCCESS и EXIT_FAILURE.

Набор имен окружения и метод изменения списка окружения, используемый функцией getenv.

Содержание и режим выполнения командной строки функцией system.

Знак значения, возвращаемого функцией сравнения (memcmp, strcmp или strncmp), если первая пара различающихся символов разнится в старшем разряде.

Содержание строк сообщений об ошибках, возвращаемых функцией strerror.

Местный временной пояс и летнее время.

Точка отсчета для функции clock.

Метрические ограничения переносимой программы

Переносимая программа должна удовлетворять следующим метрическим ограничениям:

• 15 уровней вложенности составных операторов, операторов цикла и операторов выбора варианта.
• 6 уровней вложенности условной трансляции.
• 12 описателей указателя, массива и функции, модифицирующих базовый тип в описании объекта.
• 127 выражений, вложенных друг в друга по круглым скобкам.
• 31 значащий символ в начале идентификатора с внутренней связью или имени макроопределения.
• 6 значащих символов в начале имен, имеющих внешнюю связь.
• 511 внешних имен в одном исходном файле.
• 127 имен в одном блоке.
• 1024 имени макроопределений, одновременно действующих в одном исходном файле.
• 31 параметр в вызове или определении функции.
• 31 параметр в макровызове или макроопределении с параметрами.
• 509 символов в одной логической исходной строке.
• 509 символов в строковой константе (после конкатенации).
• 32767 байтов для размещения объекта.
• 8 уровней вложенности по включаемым файлам.
• 255 меток выбора варианта в переключателях.

Обеспечение независимости от особенностей версии ОС UNIX

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

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

Бинарная совместимость

Если обычно достижение мобильности прикладных программ является целью прикладных программистов, то иногда достижение бинарной совместимости при выполнении прикладных программ является задачей разработчиков операционных систем. Под бинарной совместимостью операционной системы О2 с операционной системой О1 понимается возможность выполнения в среде О2 без перекомпиляции (а, возможно, и без перекомпоновки) приложений, написанных для выполнения в среде О1. Естественно, что бинарная совместимость двух операционных сред теоретически достижима только в том случае, когда обе операционные системы О1 и О2 базируются на некоторой общей аппаратной платформе (реально, чаще всего приходится слышать о бинарной совместимости разных вариантов ОС UNIX, работающих на платформах Intel).

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

Возможности достижения бинарной совместимости

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

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

Преимущества и ограничения

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

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