Rozdział 24
•Jak dowiedziałoś się z poprzednich rozdziałów tego podręcznika. język C umożliwia tworzenie programów, które mogą być uruchamiane na różnych platformach sprzętowych pod warunkiem ich powtórnej kompilacji. Język C należy <ki grupy języków wysokiego poziomu, które tłumaczone są do poziomu kodu maszynowego (tzn. kod źródłowy jest kompilowany). Z jednej strony jest to korzystne posunięcie, gdyż programy są szybsze i mniejsze niż programy napisane w językach interpretowanych (takich, w których kod źródłowy nie jest kompilowany do kodu maszynowego, tylko na bieżąco interpretowany przez tzw. interpreter). Jednak istnieje także druga strona medalu pewne zawiłości sprzętu, które ograniczają przenośność programów. Ten rozdział ma wyjaśnić Ci mechanizmy działania sprzętu w taki sposób, abyś l>ez problemu mógł tworzyć poprawne i całkowicie przenośne programy.
W trakcie czytania kolejnych rozdziałów można było się natknąć na zwroty takie jak zachowanie niezdefiniowane (ang. unde.fined behaviour) czy zachowanie zależne od implementacji (ang. implcmcntation-dcfincd bchatńour). Cóż one tak właściwie oznaczają?
Zacznijmy od tego drugiego. Autorzy standardu języka C czuli, że wymuszanie jakiegoś konkretnego działania danego wyrażenia byłoby zbytnim ol>ciążeniem dla osób piszących kompilatory, gdyż dany wymóg mógłby być bardzo trudny <k> zrealizowania na konkretnej architekturze. Dla przykładu, gdyby standard wymagał, że typ uusigned char ma dokładnie 8 bitów to napisanie kompilatora dla architektury, na której bajt ma 9 bitów byłoby cokolwiek kłopotliwe, a z pewnością wynikowy program działałby o wiele wolniej niżby to było możliwe.
Z tego właśnie powodu, niektóre aspekty języka nie są okreśkme bezpośrednio w standardzie i są pozostawione do decyzji zes|>ołu (osoby) |>iszącego konkretną implementację. W ten sposół). nie ma żadnych przeciwwskazań (ze strony standardu), aby na architekturze, gdzie bajty mają 9 bitów, typ char również miał tyle bitów. Dokonany wybór musi być jednak opisany w dokumentacji kom|>ilatora. tak żeby osoł>a pisząca program w C mogła sprawdzić jak dana konstrukcja zadziała.
Należy zatem pamiętać, że |x>legauie na jakimś konkretnym działaniu programu w przytułkach zachowania zależnego od implementacji drastycznie zmniejsza przenośność kodu źródłowego.
Zachowania niezdefiniowane są o wiele groźniejsze, gdyż zaistnienie takowego może spo-wodować dowolny efekt, który nie musi być nigdzie udokumentowany. Przykładem może tutaj być prólw odwołania się do wartości wskazywanej przez wskaźnik o wartości NULL.
Jeżeli gdzieś w naszym programie zaistnieje sytuacja niezdefiniowanego zachowania, to nie jest już to kwestia przenośności kodu, ale po prostu błędu w kodzie, chyba że świado-
171