Мобільне програмування в середовищі ОС UNIX

Зміст

Мобільне програмування в середовищі ОС UNIX

Стандартні бібліотеки

Бібліотека системних викликів

Бібліотека введення/виводу

Додаткові бібліотеки

Файли заголовків

Мобільність на рівні вихідних текстів

Особливості мобільного програмування мовою Сі

Забезпечення незалежності від особливостей версії ОС UNIX

Бінарна сумісність

Можливості досягнення бінарної сумісності

Переваги та обмеження Стандартні бібліотеки

Очевидним вимогою до операційному середовищі, що підтримує мобільне прикладне програмування, є те, що всі функції, що надаються нею прикладній програмі, повинні бути чітко специфікована і повинні точно відповідати цим специфікаціям в будь-якій реалізації операційного середовища. У UNIX-орієнтованих середовищах це вимога задовольняється за рахунок наявності декількох стандартизованих бібліотек функцій та відповідних наборів файлів заголовків (header-файлів). Бібліотека системних викликів

Базовою бібліотекою будь-якого варіанту системи UNIX є бібліотека системних викликів. Зараз неможливо знайти два варіанти ОС UNIX з різними назвами, набори системних викликів яких повністю б співпадали. Однак, будь-який такий варіант підтримує системні виклики, які специфікована в стандартах, що згадуються в розділі 7.5. До повністю стандартним системним викликам відносяться системні виклики для роботи з файлами (включаючи спеціальні файли), системні виклики для управління процесами (fork і сімейство exec), системні виклики класу IPC (хоча, як ми згадували в п. 3.5.4, в UNIX System V механізм програмних каналів реалізований не у вигляді набору системних викликів ядра ОС, а як набір бібліотечних функцій над пакетом TLI). Наведене в дужках зауваження насправді є дуже важливим. Користувача, який прагне створити мобільний додаток з використанням системних викликів, не повинні хвилювати деталі реалізації. Важливо, щоб склад системних викликів, їх інтерфейси і семантика відповідали стандартам.

Тепер ми можемо сформулювати правило прикладного мобільного програмування з використанням системних викликів:

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

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

Традиційною для ОС UNIX бібліотекою функцій більш високого рівня, ніж бібліотека системних викликів, є, так звана, стандартна бібліотека введення/виводу (stdio). Основний набір функцій цієї бібліотеки служить для виконання файлових операцій з буферизацією даних в пам'яті користувача процесу. Бібліотека введення/виводу фактично стандартизована дуже давно, і їй можна безпечно користуватися в будь-якій операційній середовищі. Зокрема, одноманітні бібліотеки введення/виводу підтримуються в усіх сучасних реалізаціях системи програмування мови Сі, виконаних не в середовищі ОС UNIX (включаючи реалізації в середовищі MS-DOS).

Тому можна сформулювати правило мобільного програмування з використанням бібліотеки введення/виводу:

Якщо для розробляється вами прикладної програми достатньо можливостей бібліотеки введення/виводу, обмежтеся використанням цієї бібліотеки.

Дотримуючись цього правила, з великою ймовірністю ви не будете мати проблем, пов'язаних з введенням/висновком, при перенесенні вашої програми в будь-яку операційне середовище (не обов'язково UNIX-орієнтовану), в якій підтримується стандартна бібліотека введення/виводу. Додаткові бібліотеки

Зрозуміло, що при прикладному програмуванні використовуються не тільки бібліотеки системних викликів і введення/виводу. Існує маса інших бібліотечних функцій, призначених, наприклад, для різноманітних перетворень форматів даних, математичних обчислень і т.д. До таких бібліотекам потрібно ставитися дуже обережно, оскільки з метою підвищення ефективності відповідні функції можуть бути машинно-залежними і з цієї причини володіти специфічними інтерфейсами (хоча, швидше за все, не залежать від особливостей операційної системи). Сама по собі машинна залежність бібліотечної функції не є небезпечним, оскільки при переносі програми на комп'ютер з іншого архітектурою все одно буде потрібно перекомпіляція і перекомпоновка прикладної програми, але специфічність інтерфейсів може заподіяти великі неприємності.

Найбільш безпечним рішенням на сьогоднішній день (при програмуванні на мові Сі) є використання бібліотек, специфіковані в стандарті мови Сі. Напевно, стандартних бібліотек Сі виявиться недостатньо у випадку складних додатків, але якщо за умов згадування опції "ANSI" ваша система програмування успішно виробляє складання виконуваної програми, можна бути майже впевненим, що ви не будете мати проблем при переносі програми на комп'ютер, на якому встановлений компілятор стандартного мови Сі.

Тому можна сформулювати правило мобільного програмування з використанням додаткових бібліотек:

Якщо для розробляється вами прикладної системи виявляється достатнім використання бібліотек, специфіковані в стандарті мови Сі, обмежтеся використанням цих бібліотек.

Якщо стандартних бібліотек виявляється недостатньо і доводиться використовувати функцію з деякої додаткової бібліотеки, яка підтримується в вашій системі, постарайтеся перевірити, наскільки вона стандартна. Якщо ви не впевнені в стандартності використовуваної функції, то краще напишіть власну інтерфейсну функцію з відомим вам інтерфейсом, а при перенесенні прикладної програми зістикують цю функцію (можливо, доведеться її переписати) з підходящої бібліотечної функцією цільової системи (проте немає гарантії, що вам вдасться її знайти). Файли заголовків

Використання текстових файлів заголовків (header-файлів), які вставляються в текст програми на мові Сі за допомогою директиви include препроцесора С, є традиційною технікою програмування на мові Сі в середовищі ОС UNIX, що забезпечує синтаксичну правильність використання бібліотечних функцій (в тому числі і системних викликів) в прикладній програмі. Раніше файли заголовків, головним чином, містили визначення типів і символічних констант (символічні константи - це константи, яким зіставлені імена за допомогою директиви define препроцесора С), використовуваних в інтерфейсах відповідних бібліотечних функцій. Коректне застосування файлів заголовків дозволяло програмістам не піклуватися про правильності типів даних, що використовуються при зверненні до бібліотечних функцій і обробці їх результатів.

Однак, традиційні файли заголовків не гарантували того, що набір параметрів викликається бібліотечної функції відповідав її інтерфейсу, оскільки оголошення функції, що містить її інтерфейс, у файлі компіляції було відсутнє. У кращому разі помилки такого роду стійко виявлялися під час виконання програми, хоча далеко не завжди було просто зрозуміти їх природу. У гіршому випадку помилка виникала при переносі програми, оскільки однойменні бібліотечні функції дійсно мали різними інтерфейсами в різних середовищах, і у вихідній операційному середовищі помилки в параметрах не було.

Цю проблему вдалося вирішити (хоча й не абсолютно) за рахунок введення в мову Сі поняття прототипу функції. Грубо кажучи, прототип функції - це частина її оголошення, що містить тільки інтерфейс (без тіла функції). Наявність прототипу будь-якої функції допускається в будь-якому файлі компіляції, навіть не обов'язково що містить виклик цієї функції. Однак, якщо виклик функції включених до компіляції, то набір параметрів виклику повинен точно відповідати інтерфейсу викликається функції, визначеному в її прототип.

Подальший хід міркувань очевидна. Для групи споріднених бібліотечних функцій робиться загальний файл заголовків, що містить необхідні визначення типів даних і символічних констант, а також набір прототипів цих бібліотечних функцій. Після використання в файлі компіляції такого файлу заголовків на стадії компіляції будуть виявлені всі синтаксичні помилки звернення до бібліотечних функцій. У попередньому параграфі ми відзначили, що це рішення не абсолютно. Це дійсно так, оскільки в принципі ніхто не може змусити програміста на мові Сі включати в текст програми всі необхідні файли заголовків. Однак, така специфіка світу програмування: кожен може ускладнювати своє життя в такій мірі, в якій йому чи їй це подобається.

Останнє зауваження щодо файлів заголовків. Останнім часом вони містять велику кількість операторів умовної компіляції, що відносяться більшою частиною до визначення символічних констант. Справа в тому, що залежно від версії операційної системи (ми маємо на увазі версії однієї лінії ОС UNIX, наприклад, UNIX System V) значення констант, що використовуються з одним і тим же змістом, часто змінюються. Звичайно, прикладна програма не повинна залежати від таких змін. Наявність операторів умовної компіляції всередині файлу заголовків вирішує цю проблему.

Тому останнє правило цього розділу можна сформулювати наступним чином:

При програмуванні на мові Сі з використанням бібліотечних функцій використовуйте всі необхідні файли заголовків. Це допоможе швидше знайти помилки і підвищить мобільність прикладної програми. Мобільність на рівні вихідних текстів

Матеріал, розглянутий нами в попередньому розділі, відноситься до питань мобільного програмування в зв'язку з використанням функцій операційної середовища. Однак, якщо говорити про переносимості програм між комп'ютерами з різною архітектурою, маючи на увазі використання мови Сі (не дуже високої рівня), то потрібно враховувати ряд вимог, яким повинна задовольняти програма. Особливості мобільного програмування мовою Сі

Особлива роль мови програмування Сі полягає в тому, що він, з одного боку, дозволяє писати для UNIX-систем практично настільки ж ефективний код, що й мови асемблера, а з іншого, є основним засобом перенесення програм між UNIX-системами. Можна сказати, що Сі є машинно-незалежною мовою асемблера для UNIX-систем. Це робить його основним засобом написання ефективних і переносних програм для цього класу обчислювальних систем. Стандартизація мови спочатку Американським національним інститутом стандартів (ANSI), а потім і Міжнародною організацією з стандартів (ISO) закріпила цю роль, поширивши її й на персональні комп'ютери. Будемо посилатися на версію мови Сі, визначену стандартом, як на мова ANSI C.

Сказане не означає, що будь-яка програма, написана на ANSI C і налагоджена в одній обчислювальній системі (НД), безумовно переносимо на будь-яку іншу обчислювальну систему, також має компілятор мови Сі, що відповідає вимогам ANSI. Однак, мова ANSI C визначено таким чином, щоб можна було писати програми, що піддаються мінімальним змінам при їх перенесення на інші обчислювальні системи.

Программа на ANSI C переносимо з іншої НД в цільову, якщо вона успішно компілюється до цільового НД і її робота функціонально еквівалентна роботі в вихідної нд

На переносимість програми впливають особливості як апаратного, так і програмного оточення мови у початковій і в цільової нд Можна виділити чотири фактори, що впливають на переносимість програми:  архітектура обчислювальних систем;  метричні обмеження компіляторів;  алгоритми роботи компіляторів;  особливості операційних систем.

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

Навіть якщо програма задовольняє всім обмеженням ANSI C і пройшла стадію компіляції у вихідній НД, може статися, що в цільової нд вона цю стадію НЕ пройде через те, що деякі метричні характеристики програми не задовольняють обмеженням, прийнятим до цільового нд Прикладами таких характеристик є: число рівнів вкладеності складових операторів, операторів циклу та операторів вибору варіанту; число описувачів покажчика, масиву і функції, що модифікують базовий тип в описі об'єкта; число виразів, вкладених один в одного по круглих дужках і т.п.

Від алгоритмів роботи компілятора залежить, наприклад, порядок обчислення виразів, що впливає як на значення виразів, так і на що виробляється ними побічний ефект.

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

Всі перераховані фактори враховані у визначенні ANSI C шляхом фіксування неуточняемого (стандарту) поведінки програм, невизначеного поведінки програм і поведінки програм, що визначається реалізацією.

Неуточняемое поведінка (unspecified behavior) - це поведінка правильних програм з коректними даними в ситуаціях, для яких стандарт не висуває жодних вимог.

Невизначена поведінка (undefined behavior) - поведінка (динамічно) помилкових програм з можливо некоректними даними або об'єктами з невизначеними значеннями, для яких стандарт не висуває ніяких вимог. Діапазон невизначеного поведінки може бути дуже різноманітний: від повного ігнорування ситуації з непередбачуваними результатами до поведінки (під час трансляції або виконання) згідно з документацією, описує характеристики середовища (з видачею діагностичних повідомлень або без такої); можливі випадки передчасного завершення трансляції або обчислень (з обов'язковою видачею діагностичного повідомлення).

Поведінка, обумовлене реалізацією (implementation-defined behavior) - поведінка правильно написаної програми з правильними даними, що залежить від функцій реалізації і яка має бути документовано кожної реалізацією.

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

Інша загальна рекомендація полягає у використанні можливостей препроцесора С для локалізації нестерпним фрагментів програми. Це стосується використання макроімен замість явних констант, що залежать від реалізації; використання умовної трансляції для включення в остаточний текст програми того чи іншого фрагмента в залежності від обчислювальної системи (особливо це стосується конструкцій, чия поведінка визначається реалізацією та суттєво впливає на результат роботи програми) і т.д.

Далі ми перераховуємо всі випадки неуточняемого, невизначеного і залежного від реалізації поведінки програм, а, крім того, в найменш очевидних випадках пояснюємо їх вплив на переносимість. Після цього наводяться вимоги стандарту до метричних обмеженням компіляторів.

Неуточняемое поведінка

Не уточнюються наступні питання:  Метод і час ініціації статичних даних.

Залежно від того, обчислюються чи ініціюють вирази зі сталими в оточенні трансляції або в оточенні виконання програми, статичні дані можуть отримувати різні початкові значення.  Ситуація, коли видається друкований символ, а активна позиція      знаходиться в кінці рядка.  Ситуація, коли видається символ "крок назад", а активна      позиція знаходиться на початку рядка.  Ситуація, коли видається символ "горизонтальна      табуляція ", а активна позиція знаходиться" на "або      "за" останньою о?? ределенной позицією горизонтальної табуляції.  Ситуація, коли видається символ "вертикальна      табуляція ", а активна позиція знаходиться" на "або      "за" останньою певною позицією вертикальної табуляції.

Попередні чотири ситуації впливають на виведення тексту на дисплеї.  Представлення плаваючих типів.

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

За винятком тих випадків, коли порядок обчислення виразу зафіксований синтаксичними правилами або зазначено в стандарті будь-яким іншим чином (для операції виклику функції (), операцій логічного множення, логічного додавання, умовної операції та операції перерахування виразів), порядок обчислення подвираженій і порядок виникнення побічних ефектів не уточнюється. Вираз, що містить більше, ніж одне входження однієї і тієї ж комутативність і асоціативної бінарної операції (*, +, &, ^, |), може вільно перегруповуватися, незалежно від наявності дужок, за умови, що типи операндів або результати від такої перегрупування не зміняться. У переносимої програмі слід уникати виразів, порядок обчислення яких істотно впливає на їхнє значення або виробляються побічні ефекти. Якщо ж такий вислів виникає, то що містить його оператор завжди можна розбити на еквівалентну послідовність з декількох операторів, що не містять подібних виразів. Наприклад, оператор

x = f () + g ();

можна замінити на послідовність операторів

y = f ();

x = y + g ();

або

y = g ();

x = f () + y;

залежно від потрібного порядку виконання функцій f () і g ().

Щоб зафіксувати якийсь конкретний групування операцій, потрібно присвоїти значення виразу, яке потрібно явно виділити, деякого об'єкту даних, або поставити перед групуються дужками унарний оператор плюс.  Відведення пам'яті під формальні параметри.

переносних програм не повинна використовувати інформацію про розподіл пам'яті під формальні параметри, оскільки не тільки різні компілятори по-різному вирішують цю задачу, але навіть один компілятор може різним чином відводити пам'ять під формальні параметри при різних режимах своєї роботи.  Значення індикатора позиції файлу після успішного виконання      функції ungetc      для текстового потоку, до тих пір, поки не будуть введені або знищені всі      запомненние символи.  Подробиці про значення, запам'ятовується в разі успішної роботи      функції fgetpos.        Подробиці про значення, що виробляється для текстового потоку в      разі успішної роботи функції ftell.  Порядок і взаємне розташування областей пам'яті, захоплюваних      функціями calloc,      malloc      і realloc.        Який з двох елементів, які виявилися рівними при порівнянні,      повертається функцією bsearch.  Порядок розміщення в відсортованому функцією qsort      масиві двох елементів, які виявилися рівними при порівнянні.  Структура календарного часу, що повертається функцією time.      

переносних програм не використовує перераховану інформацію, оскільки вона або розрізняється для різних реалізацій мови, або навіть є випадковою в рамках однієї реалізації.

Невизначена поведінка

Поведінка не визначається для наступних ситуацій:  У вихідній програмі виявлений символ, який не входить до потрібного      набір. Виняток робиться для препроцессорних лексем, символьних і      рядкових констант, а також приміток.  Робиться спроба модифіковані строкову константу.  Ідентифікатори, які повинні позначати одну й ту саму сутність,      розрізняються хоча б одним символом.  У символьної або рядковий константі виявлена невідома      керуюча послідовність.  Лексично перший опис функції або об'єкта даних з зовнішньої      зв'язком не має файлової області видимості, а подальший опис      лексично ідентичного ідентифікатора має або внутрішню, або зовнішню      зв'язок, що суперечить першому опису.  Арифметичне перетворення дає результат, який не може      бути представлений у відведеному просторі.  Арифметична операція невірна (наприклад, ділення на 0) або      видає результат, який не можна уявити у відведеному просторі      (наприклад, переповнення або втрата значущості).  Число фактичних параметрів виклику не узгоджується з числом      формальних параметрів функції, яка не має чинного в цiй      області видимості прототипу.  Типи фактичних параметрів виклику після розширення не узгоджуються      з розширеними типами формальних параметрів функції, яка не має      що діє в даній області видимості прототипу і не має прототипу,      чинного в області видимості, відповідної області визначення      функції.  Прототип функції є в області видимості, відповідної      області визначення функції, формальний параметр описаний до типу, який      змінюється в результаті дії розширень типу, що проводяться за замовчуванням,      а функція викликається, коли в області видимості немає семантично      еквівалентного прототипу.  Викликається функція, обробна змінне число параметрів, але      прототип з еліптичної нотацією відсутній в даній області видимості.  Викликається функція з прототипом, видимим в даній області, її      формальний параметр описаний до типу, який змінюється в результаті      дії розширень типу, що проводяться за замовчуванням, але в області      визначення функції не видно семантично еквівалентного прототипу      функції.  Зустрілася невірна посилання на масив, посилання на порожній покажчик      або посилання на об'єкт, розміщений в області автоматично розподіляє      пам'яті завершився блоку.  Покажчик на функцію перетвориться в покажчик на функцію іншого      типу і використовується для виклику функції, тип якої відрізняється від      первісного.  Покажчик на об'єкт, який не є елементом масиву, що використовується      в операції додавання або віднімання константи.  Обчислюється різниця покажчиків, що відносяться до різних масивів.  Результат вирази зсувається на негативну величину або на      величину, більшу або рівну (в бітах) розміром зрушуваної результату.  Порівнюються покажчики, що належать до різних складових об'єктів.  Значення об'єкту присвоюється перекриваються по пам'яті об'єкту.        Робиться спроба змінити об'єкт, описаний як константа, з      допомогою покажчика на тип, в якому немає атрибуту const.        Об'єкт, описаний з атрибутом volatile, вказується      за допомогою покажчика на тип, який не має такого ж атрибуту.  Описи об'єкта, що має зовнішній зв'язок, у двох різних файлах або      в різних областях видимості одного файлу, дають цьому об'єкту різні типи.  Значення автоматичного неініціірованного об'єкта використовується до      перше присвоєння.  Використовується результат роботи функції, яка, однак, не      повертає ніякого значення.  Функція, обробна змінне число параметрів, визначається      без списку типів параметрів у еліптичної нотації.  Фактичний параметр макровизова не має жодної препроцессорной      лексеми.  Всередині списку параметрів макровизова є препроцессорние      лексеми, які можуть бути проінтерпретовані як директиви      препроцесора.  В результаті виконання препроцессорной операції злиття лексем      (# #) Виходить невірна препроцессорная лексема.  Ефект, який виникає в програмі при перевизначенні      зарезервованого зовнішнього ідентифікатора.  Параметр identifier      в макровизове offset      відповідає бітовому поля запису.  Фактичний параметр бібліотечної функції має невірне значення,      якщо тільки поведінка цієї функції в подібному випадку не описано явно.  Бібліотечна функція, обробна змінне число параметрів,      не були описані.  Для доступу до цієї функції assert використана      макродіректіва # undef.        Фактичний параметр функції, обробній символи, виходить за      область визначення.  Виклик функції setjmp виробляється в      іншому контексті, ніж при порівнянні з целочисленным виразом з      констант в перемикачі або в умовному операторі.  Значення автоматичного об'єкта, що не має атрибута volatile,      змінилося між викликами setjmp і longjmp.        Функція longjmp      викликається з динамічно вкладеної програми обробки сигналу.  Сигнал виникає не в результаті роботи функцій abort      або raise,      а при обробці сигналу викликається бібліотечна функція, яка не є      самою функцією signal,      або зі статичним об'єктом проробляється НЕ присвоєння йому значення      статичної змінної з атрибутом volatile типу sig_atomic_t.        Параметр parmN      макровизначеннями va_start      описується в класі регістровий пам'яті.  Коли Ви робите макроімені va_arg чергового      фактичного параметра не виявилося.  Тип фактичного параметра зі списку параметрів не узгоджується з      типом, зазначеним у макровизове va_arg.  Функція va_end      викликається без попереднього звернення до макровизову va_start.        З функції зі змінним числом параметрів, список яких був      проініціірован за допомогою макровизова va_start, повернення      проводиться до виклику va_end.  Формат у функціях fprintf і fscanf      не відповідає переліку фактичних параметрів.  У форматі функцій fprintf або fscanf      виявлена невірна специфікація перетворення.  Серед специфікатор перетворення для специфікації, що не входить      в список o, x, X, e, E, f, g і G зустрівся ознака #.  Фактичним параметром функції fprintf, не      відповідним перетворенням% s та% p, є складовою об'єкт або      покажчик на складовою об'єкт.  Окрему перетворення у функції fprintf породило      понад 509 вихідних символів.  Фактичним параметром перетворення% p функції fscanf      є значення покажчика, видане при перетворенні% p функцією fprintf      під час попередніх запусків програми.  Результат перетворення, що виконується функцією fscanf,      не може бути представлений в обсязі пам'яті, відведеної для нього, або      отриманий об'єкт має невідповідний тип.  Результат перетворення рядка в число за допомогою функцій atof,      atoi      або atol      не може бути представлений.  Фактичний параметр функцій free або realloc      не співпадає з раніше отриманими покажчиками, виробленими функціями calloc,      malloc      або realloс,      або вказується об'єкт, раніше знищений викликом функцій free      або realloc.        Посилання на пам'ять, звільнену функціями free      або realloc.        Коли Ви робите з функції exit функція,      зареєстрована зверненням до atexit, виробляє      доступ до автоматичного об'єкту програми.  Результат цілочисельних арифметичних функцій (abs,      div,      labs      або ldiv)      не може бути представлений.  Масив, в який іде запис копіюванням або конкатенації,      замалий.  Опції memcpy,      strcpy      або strncpy      копіюють об'єкт в перекривається з ним по пам'яті інший об'єкт.  У форматі функції strftime виявлена      невірна специфікація перетворення.

Всі перераховані ситуації є помилковими, однак різні реалізації можуть по-різному реагувати на них. Може навіть трапитися, що в деяких реалізаціях програми з невизначеним поведінкою працюють і видають потрібні результати. Однак такі програми, як правило, неможливо перенести на іншу обчислювальну систему.

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

Виникнення ситуацій з невизначеним поведінкою можна, а при розробці переносних програм, безумовно, потрібно уникати.

Поведінка, залежне від реалізації

Кожна реалізація повинна описати поведінку у всіх ситуаціях, перерахованих в цьому розділі.

Семантика фактичних параметрів функції main.

Для полегшення перенесення програми корисно локалізувати обробку зовнішніх аргументів.

Число значущих початкових символів (понад 31) в ідентифікаторі без зовнішнього зв'язку.

У переносимої програмі не використовується понад 31 значущого символу в ідентифікаторах без зовнішнього зв'язку.

Число значущих початкових символів (понад 6) в ідентифікаторі із зовнішнім зв'язком.

У переносимої програмі не використовується понад 6 значущих символів в ідентифікаторах із зовнішнім зв'язком.

Чи має значення регістр символів, що входять до ідентифікатори з зовнішнім зв'язком.

При розробці переносних програм краще виходити з того, що регістр символів, що входять до ідентифікатор з зовнішньої зв'язком, не має значення (тобто не розрізняються великі та прописні літери).

Символи вхідного алфавіту, крім явно визначених у стандарті.

Це стосується, в основному, символів, що використовуються в символьних та строкових константах (наприклад, українські літери).

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

У переносите програмах небажане використання інформації про коди символів, оскільки вони можуть відрізнятися в різних реалізаціях.

Відповідність символів вхідного алфавіту (в символьних та строкових константах) символів алфавіту часу виконання.

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

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

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

Число і порядок проходження розрядів в символах з набору символів часу виконання.

Значення символьної константи, що складається з символу або керуючої послідовності, НЕ представимо в алфавіті часу виконання.

переносних програм не слід використовувати інформацію цих двох пунктів.

Значення символьної константи, що складається більш, ніж з одного символу.

У переносимої програмі не слід використовувати символьні константи більше, ніж з одного символу.

Чи слід трактувати "прості" символьні об'єкти як знакові або беззнакові.

переносних програм не повинна залежати від того, чи є тип char знаковим або беззнакові.

Представлення та набори значень різних цілочисельних типів.

У переносимої програмі краще за все виходити з мінімальних наборів значень, зафіксованих стандартом, а також з тієї мінімальної інформації про поданні, яка приводиться в стандарті.

Результат перетворення цілого до більш коротким знакової цілому або результат перетворення беззнакові цілого до знакової цілому тієї ж довжини, якщо значення не може бути представлено.

переносних програм не використовує цю інформацію.

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

У переносимої програмі слід використовувати тільки такі порозрядним операції, результат яких не залежить від реалізації.

Знак залишку цілочисельного поділу.

переносних програм не використовує цю інформацію.

Чи є зрушення вправо значення знакового целочісленного типу логічним або арифметичним.

переносних програм не повинна залежати від виду зсуву вправо знакових цілих.

Представлення та набори значень різних типів дійсних чисел.

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

Спосіб округлення, коли дійсне число перетвориться до більш вузького дійсне число.

У переносимої програмі краще за все виходити з того, що спосіб округлення невідомий.

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

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

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

переносних програм не повинна використовувати інформацію попередніх трьох пунктів.

Елемент суміші union використовується як елемент іншого типу.

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

Доповнення порожнеч і вирівнювання елементів записів.

Це звичайно не доставляє проблем, якщо тільки двійкові дані, записані однією реалізацією, не читаються інший. Звичайно ж, не слід використовувати цю інформацію в переносимої програмі.

Чи вважається "просте" ціле бітове поле знаковим або беззнакові.

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

Порядок розташування бітових полів в цілому.

Чи може бітове поле перетинати фізичні межі комірок пам'яті.

переносних програм не повинна використовувати всю цю інформацію.

Максимальне число описувачів, які можуть модифікувати базовий тип.

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

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

переносних програм повинна виходити з того, що кількість варіантів в перемикачі не повинно перевищувати 255.

Чи буде значення односімвольной символьної константи у виразі, що управляє умовним включенням фрагментів програм, збігатися зі значенням такий же константи в наборі символів оточення виконання. Чи може така константа мати негативне значення.

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

Обробка імен в лапках, що відносяться до включаються файлів.

Поведінка кожної директиви # pragma.

Визначення імен __DATE__ і __TIME__, коли, відповідно дата і час трансляції не може бути доступно.

Константа, що виходять при підстановці макровизначеннями NULL, що позначає порожній покажчик.

Попередні 6 пунктів описують залежне від реа