C/Przenośność programów: Różnice pomiędzy wersjami
Usunięta treść Dodana treść
m - porządek bitów |
Totalna przebudowa rozdziału. |
||
Linia 1:
Jak dowiedziałeś 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.
== Niezdefiniowane zachowanie i zachowanie zależne od implementacji ==
W trakcie czytania kolejnych rozdziałów można było się natknąć na zwroty takie jak zachowanie niezdefiniowane (ang. ''undefined behaviour'') czy zachowanie zależne od implementacji (ang. ''implementation-defined behaviour''). 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 obciążeniem dla osób piszących kompilatory, gdyż dany wymógł mógłby być bardzo trudny do zrealizowania na jakiejś architekturze. Dla przykładu, gdyby standard wymagał, że typ unsigned 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 mógł.
Z tego właśnie powodu, niektóre aspekty języka nie są określone bezpośrednio w standardzie i są pozostawione do decyzji zespołu (osoby) piszącego konkretną implementację. W ten sposób, 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 kompilatora, tak żeby osoba pisząca program w C mogła sprawdzić jak dana konstrukcja zadziała.
Należy zatem pamiętać, że poleganie na jakimś konkretnym działaniu programu w przypadkach 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 spowodować dowolny efekt, który nie musi być nigdzie udokumentowany. Przykładem może tutaj być próba 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 to już nie jest kwestia przenośności kodu, ale po prostu błędu w programie, aczkolwiek nie zawsze. Otóż nic nie stoi na przeszkodzie, aby konkretny kompilator opisał działanie jakiegoś wyrażenia, które według standardu wpada w omawianą klasę zachowań. Tak często bywa z operatorem przesunięcia bitowego działającego dla liczb ujemnych - w takich wypadkach nadal pozostaje jednak kwestia przenośności kodu i jeżeli zależy nam na niej nie możemy korzystać z takich funkcji kompilatora.
Istnieje jeszcze trzecia klasa zachowań. Zachowania nieokreślone (ang. ''unspecified behaviour''). Są to sytuacje, gdy standard określa kilka możliwych sposobów w jaki dane wyrażenie może działać i pozostawia kompilatorowi decyzję co z tym dalej zrobić. Coś takiego nie musi być nigdzie opisane w dokumentacji i znowu poleganie na konkretnym zachowaniu jest błędem. Klasycznym przykładem może być kolejność obliczania argumentów wywołania funkcji.
== Rozmiar zmiennych ==
Rozmiar poszczególnych typów danych (np. char, int czy long) jest różna na różnych platformach, gdyż nie jest definiowany w sztywny sposób, jak np. "long int zawsze powinien mieć 64 bity" (takie określenie wiązałoby się z wyżej opisanymi trudnościami), lecz w na zasadzie zależności typu "long powinien być nie krótszy niż int", "short nie powinien być dłuższy od int". Pierwsza standaryzacja języka C zakładała, że typ int będzie miał taki rozmiar, jak domyślna długość liczb całkowitych na danym komputerze, natomiast modyfikatory short oraz long zmieniały długość tego typu tylko wtedy, gdy dana maszyna obsługiwała typy o mniejszej lub większej długości<ref>Dokładniejszy opis rozmiarów dostępny jest w rozdziale [[C/Składnia#Typy_danych|Składnia]].</ref>.
Z tego powodu, nigdy nie zakładaj, że dany typ będzie miał określony rozmiar. Jeżeli potrzebujesz typu o konkretnym rozmiarze (a dokładnej konkretnej liczbie bitów wartości) możesz skorzystać z pliku nagłówkowego stdint.h wprowadzonego do języka przez standard ISO C z 1999 roku. Definiuje on typy int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t i uint64_t (o ile w danej architekturze występują typy o konkretnej liczbie bitów).
Jednak możemy posiadać implementację, która nie posiada tego pliku nagłówkowego. W takiej sytuacji nie pozostaje nam nic innego jak tworzyć własny plik nagłówkowy, w którym za pomocą słówka '''typedef''' sami zdefiniujemy potrzebne nam typy. Np.:
typedef unsigned char u8;
typedef signed char s8;
typedef unsigned short u16;
typedef signed short s16;
typedef unsigned long u32;
typedef signed long s32;
typedef unsigned long long u64;
typedef signed long long s64;
Aczkolwiek należy pamiętać, że taki plik będzie trzeba pisać od nowa dla każdej architektury na jakiej chcemy kompilować nasz program.
== Porządek bajtów i bitów ==
=== Bajty i słowa ===
Wiesz zapewne, że podstawową jednostką danych jest bit
Skąd takie nazwy? Otóż pochodzą one z książki ''Podróże Guliwera'', w której liliputy kłóciły się o stronę, od której należy rozbijać jajko na twardo. Jedni uważali, że trzeba je rozbijać od grubszego końca (big-endian) a drudzy, że od cieńszego (little-endian). Nazwy te są o tyle trafne, że w wypadku procesorów wybór kolejności bajtów jest sprawą czysto polityczną, która jest technicznie neutralna.
Sprawa się jeszcze bardziej komplikuje w przypadku typów, które składają się np. z 4 bajtów. Wówczas są aż 24 (4 silnia) sposoby zapisania kolejnych fragmentów takiego typu. W praktyce zapewne spotkasz się jedynie z kolejnościami big-endian lub little-endian, co nie zmienia faktu, że inne możliwości także istnieją i przy pisaniu programów, które mają być przenośne należy to brać pod uwagę.
Poniższy przykład dobrze obrazuje oba sposoby przechowywania zawartości zmiennych w pamięci komputera (przyjmujemy CHAR_BIT == 8 oraz sizeof(long) == 4, bez bitów wypełnienia (ang. ''padding bits'')): <tt>unsigned long zmienna = 0x01020304;</tt> w pamięci komputera będzie przechowywana tak:
adres | 0 | 1 | 2 | 3 |
big-endian |0x01|0x02|0x03|0x04|
little-endian |0x04|0x03|0x02|0x01|
=== Konwersja z jednego porządku do innego ===
Czasami zdarza się, że napisany przez nas program musi się komunikować z innym programem (może też przez nas napisanym), który działa na komputerze o (potencjalnie) innym porządku bajtów. Często najprościej jest przesyłać liczby jako tekst, gdyż jest on niezależny od innych czynników, jednak taki format zajmuje więcej miejsca, a nie zawsze możemy sobie pozwolić na taką rozrzutność.
Przykładem może być komunikacja sieciowa, w której przyjeło się, że dane przesyłane są w porządku big-endian. Aby móc łatwo operować na takich danych standard POSIX definiuje następujące funkcje (w zasadzie zazwyczaj są to makra):
#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);
Pierwsze dwie konwertują liczbę z reprezentacji lokalnej na reprezentację big-endian (''host to network''), natomiast kolejne dwie dokonują konwersji w drugą stronę (''network to host'').
Można również skorzystać z pliku nagłówkowego endian.h, w którym definiowane są makra pozwalające określić porządek bajtów:
#include <endian.h>
#include <stdio.h>
int main
#if __BYTE_ORDER == __BIG_ENDIAN
printf
#elif __BYTE_ORDER == __LITTLE_ENDIAN
printf("Porządek little-endian (1234)\n");
#elif defined __PDP_ENDIAN && __BYTE_ORDER == __PDP_ENDIAN
printf("Porządek PDP (3412)\n");
#else
printf
#endif
return 0;
}
Na podstawie makra __BYTE_ORDER można skonstruować funkcję, która będzie konwertować liczby pomiędzy porządkiem różnymi porządkami:
#include <endian.h>
#include <stdio.h>
#include <
uint32_t convert_order32(uint32_t val, unsigned from, unsigned to) {
if (from==to) {
return val;
} else {
uint32_t ret =
unsigned char tmp[5] = { 0, 0, 0, 0, 0
unsigned char *ptr = (unsigned char*)&val;
unsigned div = 1000;
do tmp[from / div % 10] = *ptr++; while ((div /= 10));
ptr = (unsigned char*)&ret;
div = 1000;
do *ptr++ = tmp[to / div % 10]; while ((div /= 10));
return ret;
}
#define LE_TO_H(val) convert_order32((val), 1234, __BYTE_ORDER)
#define H_TO_LE(val) convert_order32((val), __BYTE_ORDER, 1234)
#define BE_TO_H(val) convert_order32((val), 4321, __BYTE_ORDER)
#define H_TO_BE(val) convert_order32((val), __BYTE_ORDER, 4321)
#define PDP_TO_H(val) convert_order32((val), 3412, __BYTE_ORDER)
#define H_TO_PDP(val) convert_order32((val), __BYTE_ORDER, 3412)
int main (
{
printf("%08x\n", LE_TO_H(0x01020304));
printf
printf("%08x\n", BE_TO_H(0x01020304));
printf("%08x\n", H_TO_BE(0x01020304));
printf("%08x\n", PDP_TO_H(0x01020304));
printf("%08x\n", H_TO_PDP(0x01020304));
return 0;
}
Ciągle jednak polegamy na niestandardowym pliku nagłówkowym endian.h. Można go wyeliminować sprawdzając porządek bajtów w czasie wykonywania programu:
#include <stdio.h>
#include <stdint.h>
int main() {
uint32_t val = 0x04030201;
unsigned char *v = (unsigned char *)&val;
int byte_order = v[0] * 1000 + v[1] * 100 + v[2] * 10 + v[3];
if (byte_order == 4321) {
printf("Porządek big-endian (4321)\n");
} else if (byte_order == 1234) {
printf("Porządek little-endian (1234)\n");
} else if (byte_order == 3412) {
printf("Porządek PDP (3412)\n");
} else {
printf("Inny porządek (%d)\n", byte_order);
}
return 0;
}
Powyższe przykłady opisują jedynie część problemów jakie mogą wynikać z próby przenoszenia binarnych danych pomiędzy wieloma platformami. Wszystkie co więcej zakładają, że bajt ma 8 bitów, co wcale nie musi być prawdą dla konkretnej architektury, na którą piszemy aplikację. Co więcej liczby mogą posiadać w swojej reprezentacje bity wypełnienia (ang. ''padding bits''), które nie biorą udziały w przechowywaniu wartości liczby. Te wszystkie różnice mogą dodatkowo skomplikować kod. Toteż należy być świadomym, iż przenosząc dane binarnie musimy uważać na różne reprezentacje liczb.
== Biblioteczne problemy ==
Pisząc programy nieraz będziemy musieli korzystać z różnych bibliotek. Problem polega na tym, że nie zawsze będą one dostępne na komputerze, na którym inny użytkownik naszego programu będzie próbował go kompilować. Dlatego też ważne jest, abyśmy korzystali z łatwo dostępnych bibliotek, które dostępne są na wiele różnych systemów i platform sprzętowych. '''Zapamiętaj''': twój program jest na tyle przenośny na ile przenośne są biblioteki z których korzysta!
<noinclude>
{{Przypisy}}
| |||