Artykuł na Medal

C (język programowania)

Z Wikipedii, wolnej encyklopedii
Przejdź do nawigacji Przejdź do wyszukiwania
C
Ilustracja
Logo języka
Pojawienie się

1972

Paradygmat

imperatywny (proceduralny)

Typowanie

statyczne (słabe)

Implementacje

Borland Turbo C, GCC, Microsoft Visual C, MinGW, LLVM, Tiny C Compiler

Pochodne

C++, Java, C#

Aktualna wersja stabilna

C18 (czerwiec 2018)[1]

Aktualna wersja testowa

C2x[2]

Twórca

Dennis Ritchie

Platforma sprzętowa

wieloplatformowy

Platforma systemowa

wieloplatformowy

Cimperatywny, proceduralny język programowania ogólnego przeznaczenia[3], stworzony na początku lat 70. XX wieku przez Dennisa Ritchiego, ówczesnego pracownika Bell Labs. W języku C powstały narzędzia systemowe dla Uniksa, a potem również kod systemu Unix. Język C został ustandaryzowany w 1989 roku przez ANSI. Od tego czasu jego rozwojem zajmuje się grupa robocza w ramach ISO.

Język C powstawał jako rozwinięcie języka B, wzbogacając się stopniowo o kolejne funkcje. Okresy najszybszego rozwoju języka C to lata 1972–1973 oraz 1977–1979. Z kolei lata 1980. to czas zdobywania przez niego popularności, czego efektem była dostępność kompilatorów dla praktycznie wszystkich używanych wtedy architektur komputerów i systemów operacyjnych.

C jest jednym z popularniejszych języków programowania. Służy zarówno do pisania elementów systemów operacyjnych, jak i aplikacji użytkowych. Mimo to spotyka się z krytyką z powodu pewnych decyzji projektowych, takich jak priorytety operatorów lub nadmiernie lakoniczna składnia.

Historia[edytuj | edytuj kod]

Początki C są ściśle związane z rozwojem systemu Unix, napisanego pierwotnie przez Dennisa Ritchiego i Kena Thompsona w asemblerze na komputer PDP-7. Późniejsza wersja systemu, przeznaczona na maszynę PDP-11, również powstała w asemblerze[4].

Thompson czuł potrzebę wykorzystania języka wyższego poziomu do napisania narzędzi systemowych dla Uniksa. Początkowo próbował przygotować kompilator Fortranu, lecz dość szybko porzucił ten pomysł. W zamian stworzył własną, okrojoną wersję BCPL, którą nazwał B. W języku tym powstało niewiele narzędzi, ponieważ wynikowe programy były powolne oraz nie mogły korzystać z adresowania poszczególnych bajtów pamięci (funkcji dostępnej np. w PDP-11)[4].

Wczesny rozwój[edytuj | edytuj kod]

Dennis Ritchie rozpoczął w 1972 roku rozwijanie języka B. Jedną z pierwszych zmian było dodanie typów danych dla zmiennych. Początkowo dostępne były dwa: znakowy (char) i całkowitoliczbowy (int). Wprowadzono również sposób deklarowania zmiennych typu wskaźnikowego oraz odwołań do funkcji. Tak znaczące zmiany spowodowały, że Ritchie nadał językowi nową nazwę: C[4].

Zgodnie z sugestią Alana Snydera, na początkowym etapie rozwoju języka Ritchie rozdzielił operatory koniunkcji i alternatywy na bitowe (składające się z pojedynczego symbolu) oraz logiczne (złożone z dwóch znaków). W języku B oba warianty oznaczano w taki sam sposób, a odpowiednie działanie było wybierane przez interpreter, w zależności od kontekstu[4].

Kompilator C, wraz z kilkoma programami napisanymi w tym języku, został dołączony do drugiej wersji systemu Unix[5]. Latem 1973 jądro tego systemu zostało przepisane w języku C[4].

Do tego czasu wprowadzono również do składni języka obsługę struktur. Mniej więcej w tym samym czasie powstała pierwsza wersja preprocesora. Umożliwiała ona dołączanie plików zewnętrznych (dyrektywa #include) oraz wykonywanie prostych podstawień (definiując makra bez parametrów z użyciem #define). Funkcjonalności takie jak kompilacja warunkowa czy parametryzowane makra zostały wprowadzone niedługo później – przez Mike’a LeskaInformacje powiązane z artykułem „Mike Lesk” w Wikidanych oraz Johna Reisera. Na tym etapie rozwoju języka preprocesor stanowił opcjonalny dodatek, który nie musiał być uruchamiany w trakcie kompilacji[4].

Około 1977 roku Dennis Ritchie, Ken Thompson i Stephen Johnson skupili się na przenośności oprogramowania napisanego w C[4]. W tym celu przyjrzeli się często wykorzystywanym konstrukcjom i zachowaniom, które były zależne od architektury komputera. Ponadto Johnson napisał kompilator pccInformacje powiązane z artykułem „Portable C Compiler” w Wikidanych, w którym oddzielono część związaną z architekturą od części uniwersalnej, co ułatwiło wspieranie nowych platform sprzętowych oraz utrzymanie tych już wspieranych[6][4].

K&R C[edytuj | edytuj kod]

W 1978 opublikowane zostało pierwsze wydanie książki The C Programming Language (wyd. polskie Język C, 1987[7]), autorstwa Briana Kernighana i Dennisa Ritchiego. Stanowiła ona pierwszą, nieformalną, specyfikację języka C[4]. Wersja ta bywa nazywana C78, gdzie nazwa pochodzi od roku wydania. Inne skrócone określenie, K&R C, pochodzi od nazwisk autorów książki[8].

Jeszcze przed publikacją książki do języka C włączono kwalifikatory short i long, pozwalające określić wielkość zmiennej typu całkowitoliczbowego, a także specyfikator unsigned, oznaczający liczby nieujemne[9].

W specyfikacji C78 złożone operatory przypisania uzyskały jednoznaczną składnię. Do roku 1976 instrukcja „zmniejsz wartość zmiennej i o 10” mogłaby zostać napisana jako: i =- 10, co jest bardzo podobne do polecenia zapisania w zmiennej i wartości -10. Nowe symbole cechowała zamieniona kolejność operatora i znaku równości, np. -= zamiast =-. Dwuznaczne oznaczenia wywodziły się jeszcze z języka B i sposobu przetwarzania kodu przez analizator składni[4].

W książce Kernighana i Ritchiego znalazł się również opis biblioteki wejścia/wyjścia. Podwaliny pod nią położył w 1972 roku Mike Lesk, pisząc „przenośną bibliotekę wejścia/wyjścia”. W następnych latach, wraz z pracami nad przenośnością systemu Unix, została ona rozwinięta i usprawniona. Funkcje biblioteczne nie zostały przez autorów książki uznane za część języka, lecz dodatek do niego[4][10].

Autorzy publikacji wspomnieli również o planowanym zniesieniu większości ograniczeń dotyczących struktur[11]. Do 1980 roku możliwe stało się przekazywanie ich jako parametry funkcji oraz bezpośrednie przypisywanie. Jedynie brak notacji dla literału powodował, że nie były typem pierwszoklasowym. W okresie po wydaniu książki do języka trafiło również wsparcie dla typów wyliczeniowych oraz funkcji niezwracających żadnej wartości, choć o tych kwestiach nie można znaleźć informacji w I wydaniu publikacji Kernighana i Ritchiego[4].

Język taki, jak opisany przez Kernighana i Ritchiego w 1978 roku nie przewidywał żadnej możliwości określenia typów przyjmowanych przez parametry funkcji[4]. Powstały odrębne narzędzia, takie jak lint, które przeprowadzały analizę kodu bardziej rygorystyczną niż kompilator, a następnie zgłaszały problemy ze spójnością i przestrzeganiem dobrych praktyk[6].

Książka Język C nie stanowiła ścisłego standardu. Miejscami pozostawiała miejsce do interpretacji szczegółów języka. To, w połączeniu z dalszym rozwojem i popularyzacją C na różnych platformach, spowodowało potrzebę standaryzacji[4].

W latach 80. XX wieku Bjarne Stroustrup stworzył język C++, który stanowił rozszerzenie C, dodające przede wszystkim wsparcie dla programowania obiektowego. Dodatków tych nie wcielono do C, a C++ został niezależnie ustandaryzowany przez ANSI i ISO[12].

ANSI C i ISO C[edytuj | edytuj kod]

W 1983 roku, ANSI sformowała komitet X3J11, którego celem było „sformułowanie jasnego, spójnego i jednoznacznego standardu C, który skodyfikuje powszechnie istniejący język w sposób promujący zgodność programów z różnymi środowiskami uruchomieniowymi”. Odpowiedni dokument przyjęto w 1989 roku jako standard ANSI X3.159-1989 „Język programowania C”[4]. Opisana w nim wersja języka jest zwykle określana jako ANSI C lub C89 (od daty publikacji)[8].

Rok później, w 1990 standard ANSI C został przyjęty (ze zmianami redakcyjnymi) przez Międzynarodową Organizację Normalizacyjną jako ISO/IEC 9899:1990[4][8]. Ta wersja bywa również nazywana C90 lub ISO C, choć opisuje ten sam język, co dokument ANSI[8].

Oprócz dodatków autorstwa Ritchiego, zaimplementowanych po publikacji książki Język C, komitet standaryzacyjny ANSI wprowadził do języka np. prototypy funkcji czy wskaźniki na nieznany typ (void*). W C89 pojawiła się także możliwość deklarowania typów parametrów funkcji w nagłówku, ale starsza składnia pozostała dopuszczalna dla zgodności z istniejącym kodem. Standard wzbogacił również preprocesor o dodatkowe instrukcje, takie jak #elif oraz wsparcie dla łączenia napisów (operator ##)[13]. Wzorując się na języku C++ zaadaptowano również składnię i znaczenie kwalifikatorów typu const i volatile[14].

Podczas prac nad językiem Kernighan i Ritchie nie skupiali się na ustandaryzowaniu biblioteki standardowej. Odpowiednie funkcje dostarczał system Unix, niezależnie od stosowanego kompilatora. Implementacje C na innych platformach były wyposażone w biblioteki, które starały się naśladować to, co było dostępne na Uniksie, jednak nie istniały wytyczne określające zestaw procedur, jakie muszą być udostępnione programistom. Komitet ANSI przygotował opis biblioteki standardowej języka C, wymagający dostarczenia programiście odpowiednich funkcji o ściśle określonym działaniu i przeznaczeniu[13].

W 1995 roku została opublikowana poprawka do standardu, wprowadzająca obsługę wielobajtowych kodowań znaków (ang. wide characters, typ wchar_t), wraz z zestawem funkcji do operacji na składających się z nich napisach[15]. Inne zmiany obejmują dodanie pliku nagłówkowego iso646.h, definiującego makra, których można użyć do zastąpienia niektórych operatorów słowami, jak and zamiast && czy not_eq zamiast !=. Oprócz istniejących już trójznaków (będących innym sposobem zapisania pewnych symboli), wprowadzono 6 dwuznaków o tym samym zastosowaniu: <:, :>, <%, %>, %: i %:%:[16][17]. W poprawce ustanowiono również wymóg, by implementacje ustawiały makro __STDC_VERSION__ na wartość 199409, co ma wskazywać na zgodność z nowszą wersją standardu[16].

C99[edytuj | edytuj kod]

Druga wersja standardu języka C została opublikowana przez ISO w 1999 roku. Zaczerpnęła z języka C++ funkcje inline i komentarze jednoliniowe (rozpoczynające się sekwencją //). Zdefiniowano wtedy również kolejne typy danych: long long int (minimum 64-bitowa liczba całkowita) oraz typ logiczny _Bool, który może przyjmować jedynie wartości 0 oraz 1[18][19] (wraz z makrami bool, true i false)[20]. W tej wersji standardu dodano także kolejny kwalifikator typu restrict[19].

Od standardu C99 zdefiniowany jest sposób obsługi liczb zespolonych w języku. Służą do tego typy z określeniami _Imaginary oraz _Complex[18], przechowujące – odpowiednio – wartości urojone oraz zespolone. Kwalifikatorów tych można używać jedynie z typami zmiennoprzecinkowymi[20].

W 1999 roku do języka C wprowadzono także obsługę tablic o długości ustalanej w czasie działania programu[19]. Implementacje wspierające wersję C99 powinny ustawić makro __STDC_VERSION__ na 199901[20].

C11[edytuj | edytuj kod]

Kolejna edycja standardu została przyjęta w grudniu 2011. Podczas prac nad nią, komitety odpowiedzialne za języki C i C++ współpracowały ze sobą, by zachować wzajemną zgodność obu na tyle, na ile to możliwe. W tej wersji standardu zadecydowano, że tablice o zmiennej długości oraz typy zespolone staną się funkcjonalnością opcjonalną (C99 wymagał, by kompilatory je wspierały). Rozbudowano również bibliotekę standardową o procedury sprawdzające zakres i granice obszaru pamięci podczas operowania na napisach. Z powodu licznych podatności usunięto funkcję gets(), zastępując ją bezpieczniejszą gets_s()[21].

Publikując tę wersję standardu, komitet ustandaryzował wsparcie dla wielowątkowości, m.in. definiując sposoby zarządzania i synchronizowania wątków oraz wprowadzając typy atomowe (w tym kwalifikator typu _Atomic). Umożliwiono również oznaczenie funkcji bez powrotu słowem kluczowym _Noreturn, co pozwala kompilatorom na pewne optymalizacje generowanego kodu[21].

W 2011 roku do języka C wprowadzono także mechanizm definiowania makr generycznych ze względu na typ parametrów oraz wsparcie dla literałów napisowych w standardach Unicode i UTF-8[21].

W tej wersji __STDC_VERSION__ przyjmuje wartość 201112[22].

C17 / C18[edytuj | edytuj kod]

Czwarta wersja standardu nie przyniosła żadnych znaczących zmian w języku w stosunku do C11[23]. Dokument przyjęty przez ISO w czerwcu 2018[1] przyniósł poprawki i uściślenia tekstu, dlatego zmiany w zachowaniu kompilatorów po jego implementacji wynikają z interpretacji niejednoznacznych zapisów[23]. Jedyną zmianą normatywną było nadanie wartości 201710 makro __STDC_VERSION__[22].

Iteracja ta bywa nazywana C17[23], jak i C18[24].

Składnia[edytuj | edytuj kod]

Formalna gramatyka języka C jest opisana w standardzie ISO C[25]. Podział kodu na linie oraz białe znaki są ignorowane. Ich stosowanie jest obowiązkowe jedynie, kiedy służą rozdzieleniu poszczególnych jednostek leksykalnych[26].

Program w języku C zapisywany jest w plikach źródłowych, które nie muszą być kompilowane w tym samym czasie. Plik źródłowy razem z plikami dołączonymi dyrektywą #include tworzy jednostkę tłumaczenia, która po przetłumaczeniu na kod maszynowy może być konsolidowana z innymi w celu stworzenia wykonywalnego programu[27].

Identyfikatory[edytuj | edytuj kod]

Identyfikator stanowi nazwę obiektu, funkcji, etykiety itp. Może on oznaczać różne byty w różnych momentach wykonywania programu[28]. Istotna jest jedynie określona liczba znaków w nazwie. W przypadku, gdy dwa identyfikatory różnią się jedynie znakami na nieistotnych pozycjach, zachowanie jest nieokreślone. Minimalna znacząca długość jest zależna od implementacji i może się różnić w zależności od sposobu linkowania określanego przezeń bytu[29], choć standard wymaga, by przynajmniej 63 pierwsze znaki identyfikatorów wewnętrznych i 31 początkowych znaków identyfikatorów zewnętrznych było znaczących[30].

Identyfikatory mogą składać się jedynie z liter, cyfr i znaku podkreślenia, choć cyfra nie może występować na pierwszym miejscu[29]. Aby zastosować w nazwie znaki spoza tego zbioru, konieczne jest użycie sekwencji ucieczkiInformacje powiązane z artykułem „Sekwencja ucieczki” w Wikidanych \uxxxx lub \Uxxxxxxxx (gdzie x to cyfra szesnastkowa)[31]. Na potrzeby kompilatora i powiązanej z nim biblioteki zarezerwowane są identyfikatory zaczynające się dwoma znakami podkreślenia lub podkreśleniem z następującą po nim wielką literą[32].

W zależności od tego, do czego odwołuje się identyfikator, należy on do jednej z przestrzeni nazw[33]:

Ponadto każdy identyfikator ma swój zakres widoczności, zależny od miejsca deklaracji[28].

Z identyfikatorem może być skojarzony jeden z trzech sposobów łączności: zewnętrzna, wewnętrzna lub brak. Łączność decyduje o tym, czy dwa identyczne identyfikatory w różnych miejscach programu odnoszą się do tego samego bytu[33]:

  • identyfikatory o łączności zewnętrznej odnoszą się do tego samego obiektu lub funkcji w obrębie całego programu,
  • identyfikatory o łączności wewnętrznej oznaczają ten sam byt w ramach jednej jednostki tłumaczenia,
  • identyfikatory bez łączności za każdym razem odnoszą się do innego obiektu.

Wyrażenia[edytuj | edytuj kod]

Ciąg operatorów i operandów stanowi w języku C wyrażenie. Oznacza ono obliczenie wartości lub odwołanie do obiektu. W trakcie jego wywoływania mogą także występować skutki uboczne[34] (na przykład inkrementacja zmiennej[35]). Kolejność obliczania wartości i zachodzenia skutków ubocznych jest nieokreślona, lecz zgodna z pierwszeństwem operatorów. Standard języka C gwarantuje, że zdarzą się one przed następnym punktem sekwencyjnymInformacje powiązane z artykułem „Punkt sekwencyjny” w Wikidanych[36].

Jeżeli tego samego obiektu dotyczy więcej niż jeden skutek uboczny i nie są one rozdzielone punktem sekwencyjnym, wtedy zachowanie jest nieokreśloneInformacje powiązane z artykułem „Nieokreślone zachowanie (informatyka)” w Wikidanych[36][34]. Takie punkty wprowadzane są[37]:

  • w trakcie wywoływania funkcji: przed rozpoczęciem obliczania argumentów funkcji oraz przed skokiem do funkcji;
  • między obliczeniem wartości operandów &&, ||, ,;
  • między obliczeniem wartości pierwszego operandu ?: a drugiego lub trzeciego;
  • między wywołaniem kolejnych pełnych wyrażeń;
  • w momencie powrotu z funkcji bibliotecznych oraz w niektórych przypadkach w trakcie ich działania.

Operatory[edytuj | edytuj kod]

W języku C są zdefiniowane następujące operatory[38]:

  • arytmetyczne: +, -, *, /, %
  • bitowe: ~, &, ^, |
  • dostępu: ., ->
  • grupowania wyrażeń: ()
  • inkrementacji i dekrementacji: ++, --
  • logiczne: !, &&, ||
  • porównania: <, >, <=, >=, ==, !=
  • przesunięcia bitowego: <<, >>
  • przypisania: =
  • przypisania złożonego: *=, /=, %=, +=, -=, <<=, >>=, &=, ^=, |=
  • rozmiaru obiektu: sizeof
  • rzutowania: (typ)
  • sekwencyjny: ,
  • warunkowy: ?:
  • wskaźnikowe: *, &, []
  • wyrównania dla typu: _Alignof
  • wywołania funkcji: ()

Obiekty[edytuj | edytuj kod]

Obiekt (zwany też zmienną[39]), według standardu języka C, to region pamięci środowiska wykonawczego, mogący reprezentować wartości[40]. Wyrażenie, które może odwoływać się do obiektu jest l-wartością. Jej typ określa, w jaki sposób interpretować zawartość obiektu[41].

Przykładem l-wartości jest identyfikator obiektu. Może nią być również rezultat dereferencji wskaźnika[41].

Deklaracja obiektu polega na podaniu typu danych oraz opcjonalnie klasy pamięci i sposobu linkowania, po których występuje przynajmniej jeden identyfikator tworzonego obiektu (lub obiektów)[42].

Funkcje[edytuj | edytuj kod]

W języku C rozróżniane są[43]:

  • deklaracja funkcji – polega na podaniu zwracanego typu, nazwy funkcji oraz listy parametrów (być może pustej); kończy się średnikiem
  • definicja funkcji – składa się z deklaracji oraz listy instrukcji, objętej w nawiasy klamrowe ({...}).

Definicje funkcji w języku C nie mogą być zagnieżdżane[44].

Funkcje w języku C nie mogą być przeciążane[45], ale istnieje mechanizm definiowania funkcji o zmiennej liczbie argumentów[46].

Instrukcje sterujące[edytuj | edytuj kod]

Wykorzystanie instrukcji if i switch do realizacji równoważnych fragmentów kodu.

W języku C można wyróżnić trzy klasy instrukcji sterujących. Pierwszą z nich są polecenia umożliwiające warunkowe wykonanie fragmentów kodu. Do tej grupy należą[47]:

  • if ... else – pozwala na wykonanie jednej z dwóch gałęzi kodu na podstawie wartości typu logicznego,
  • switch – wykonuje jeden z wielu bloków kodu na podstawie porównania wartości liczbowej z wyrażeniami w poszczególnych etykietach case.
Schemat blokowy pętli for.

Druga grupa instrukcji sterujących służy realizacji pętli. Każda z nich jest wykonywana tak długo, jak podany warunek jest prawdziwy. Składają się na nią[48]:

  • while – warunek jest sprawdzany przed każdą iteracją;
  • do ... while – warunek jest sprawdzany po każdej iteracji;
  • for – pozwala na określenie instrukcji, która wykona się przed pierwszą iteracją oraz instrukcji do wywołania po każdym przebiegu pętli.

Ostatnią grupę stanowią instrukcje skoku. Należą do nich[49]:

  • goto – realizuje skok do etykiety o podanej nazwie, ale nie jest możliwe wyjście z aktualnie wykonywanej funkcji;
  • continue – przerywa wykonywanie bieżącej iteracji pętli i przechodzi do kolejnej;
  • break – przerywa wykonywanie pętli lub instrukcji switch;
  • return – przerywa wykonywanie bieżącej funkcji i opcjonalnie przekazuje wartość do miejsca wywołania.

Dyrektywy preprocesora[edytuj | edytuj kod]

Dyrektywy preprocesora rozpoczynają się od znaku # i muszą znajdować się w osobnych liniach (dopuszczalne jest by przed symbolem kratki znajdowały się spacje)[50].

Preprocesor w języku C pozwala na manipulację kodem źródłowym przed właściwą kompilacją. Wspiera mechanizmy kompilacji warunkowej (dyrektywa #if i jej warianty) oraz dołączania innych plików źródłowych (#include). Odpowiada również za rozwijanie makr (zdefiniowanych przy użyciu #define)[51][52].

Dzięki dyrektywie #pragma możliwe jest przekazywanie instrukcji specyficznych dla kompilatora[53][a].

Komentarze[edytuj | edytuj kod]

W języku C występują komentarze liniowe i blokowe. Ich zawartość przetwarzana jest przez kompilator wyłącznie w celu znalezienia końca komentarza (symbolizowanego odpowiednią sekwencją lub końcem linii). Do ich wprowadzenia służą znaki /* (blokowy, kończy się */) oraz // (liniowy, trwa do końca linii). Sekwencje te tracą swoje znaczenie, jeśli znajdują się w literale tekstowym lub wewnątrz innego komentarza[54].

W trakcie kompilacji, komentarze zastępowane są znakiem spacji[27].

Typy danych[edytuj | edytuj kod]

Typ danych określa zbiór wartości, które może przyjąć dany obiekt, jak również dozwolone operacje na nim[55]. Język udostępnia zestaw typów podstawowych oraz mechanizmów konstruowania typów pochodnych[56].

Szczególnym typem danych w C jest typ pusty void, który nie przechowuje żadnej wartości. W związku z tym można wykorzystywać go jedynie w sytuacjach, gdy wartość nie jest wymagana – np. jako lewy argument operatora , lub w charakterze instrukcji. Rzutowanie tego typu na jakikolwiek inny typ, zarówno jawne, jak i niejawne jest niedozwolone[57]. Słowem void oznacza się między innymi funkcje nie zwracające nic[58].

Typy podstawowe[edytuj | edytuj kod]

W języku C istnieje kilka bazowych typów danych, które można dookreślać z użyciem odpowiednich słów kluczowych w celu uzyskania odpowiedniego zakresu wartości. Służą do przechowywania liczb całkowitych (char i int) oraz zmiennoprzecinkowych (float i double)[59].

Razem z typem int można stosować kwalifikatory short oraz long. Pozwalają one programiście wykorzystywać typy danych krótsze i dłuższe niż naturalne dla danej architektury. Ponadto nazwę każdego typu, służącego do przechowywania liczb całkowitych, można również poprzedzić słowem signed lub unsigned, aby określić, czy dany obiekt ma być w stanie przechowywać liczby ujemne[60]. Reprezentacja bitowa wartości, które można zapisać zarówno w wariancie signed, jak i unsigned danego typu jest w obu wariantach taka sama[61].

Standard języka C nie ustala w sposób sztywny zakresów wartości, jakie muszą się zmieścić w obiektach poszczególnych typów. Podobnie nie są określone ich rozmiary w bitach lub bajtach[59]. Od implementacji języka wymaga się, by poszczególne typy danych pozwalały na przechowywanie przynajmniej liczb z ustalonego przedziału[30], a w przypadku typu logicznego _Bool – by miał rozmiar wystarczający do zmieszczenia wartości 0 i 1[62].

Minimalne zakresy wartości dla typów całkowitoliczbowych[63]
Typ Minimalny zakres Minimalny rozmiar w bitach
signed char 8
unsigned char 8
short int[b] 16
unsigned short int[b] 16
int 16
unsigned int[b] 16
long int[b] 32
unsigned long int[b] 32
long long int[b] 64
unsigned long long int[b] 64

W powyższej tabeli zebrano minimalne wymagania stawiane dostępnym w C typom całkowitoliczbowym. Dodatkowym ograniczeniem, stawianym przez standard jest to, aby kolejne typy miały zakres niemniejszy od poprzednich. Na przykład obiekt typu short nie może być dłuższy niż int, który z kolei musi być niedłuższy od long[59].

Użycie kwalifikatora long jest dopuszczalne również w połączeniu z typem double, choć standard C nie gwarantuje, że uzyskany w ten sposób typ będzie miał większą pojemność niż wyjściowy. Podobnie jak w przypadku liczb całkowitych, dostępne typy zmiennoprzecinkowe również nie mają sztywno określonego zakresu wartości oraz minimalnej dokładności[65].

W czasie, gdy ukazało się pierwsze wydanie książki Język C Kernighana i Ritchiego, dopuszczalna była również konstrukcja long float, równoważna typowi double, jednak została ona zniesiona przez standard ANSI C[58].

Minimalne wymagania standardu języka C wobec typów zmiennoprzecinkowych[66]
Cecha float double long double
Liczba dziesiętnych cyfr znaczących 6 10 10
Największa liczba dodatnia
Najmniejsza dodatnia liczba znormalizowana
Epsilon maszynowy

Do typów podstawowych należy również wyliczenie. Składa się ono z listy stałych symbolicznych, każda o wartości będącej liczbą całkowitą. Typy wyliczeniowe funkcjonalnie są równoważne całkowitoliczbowym[67][58].

Typy pochodne[edytuj | edytuj kod]

Z niezerowej liczby obiektów tego samego typu można stworzyć tablicę[68]. Jej elementy są ułożone w pamięci komputera po kolei i bez żadnych przerw[69], a dostęp do nich można uzyskać za pomocą składni tablica[indeks], gdzie indeksy rozpoczynają się od zera[70][c]. Do raz utworzonej zmiennej typu tablicowego nie jest możliwe przypisanie innej tablicy[72]. Kiedy nazwa tablicy zostanie użyta w wyrażeniu, dokonuje się jej niejawna konwersja na wskaźnik do zerowego elementu tablicy. Wskaźnik ten nie może być użyty w charakterze l-wartości[41].

Do przechowywania adresu obiektu określonego typu służą wskaźniki[73]. Dozwolone jest wykonywanie na nich niektórych operacji arytmetycznych. Dowolny wskaźnik można przyrównać do zera (oznaczającego literał pusty, zapisywany też jako NULL)[74]. Porównywanie oraz odejmowanie dwóch wskaźników jest zdefiniowane wyłącznie wtedy, kiedy dotyczą one tej samej tablicy lub – wyłącznie w przypadku porównywania – tego samego obiektu złożonego[75]. Do wartości wskaźnika można również dodać lub odjąć dowolną liczbę całkowitą. Zabronione jest wykonywanie innych działań, takich jak mnożenie czy dzielenie[74]. W działaniach arytmetycznych, w których biorą udział liczby całkowite oraz wskaźniki, liczba jest traktowana jako liczba elementów tablicy odpowiedniego typu, a nie liczba bajtów[d][76].

Jedna lub kilka zmiennych może tworzyć strukturę. W przeciwieństwie do tablic, takie składowe mogą być różnych typów, a poszczególne pola rozróżnia się z użyciem ich identyfikatorów[77]. Każda struktura stanowi odrębną przestrzeń nazw, toteż pole o tej samej nazwie może występować w kilku strukturach[78][33]. Zagnieżdżanie struktur jest dozwolone – składowe mogą również być strukturami. Standard ISO C zabrania natomiast rekursywnego zagnieżdżania struktury samej w sobie. Mimo to struktura może zawierać wskaźnik na inną strukturę tego samego typu[79]. Zarówno przypisywanie do zmiennej typu strukturalnego nowej wartości, jak i przekazywanie jej jako argument oraz zwracanie z funkcji są dopuszczalnymi operacjami[80].

Układ składowych w pamięci jest zależny od implementacji, z pewnymi wyjątkami: pierwsze pole musi się zaczynać od razu na początku struktury (tak by wskaźnik na strukturę był równy co do wartości wskaźnikowi na jej pierwsze pole), a ponadto pola muszą następować w pamięci w tej samej kolejności, co w deklaracji. Dopuszcza się jednak istnienie niewykorzystanych i nienazwanych przestrzeni w środku oraz na końcu struktury[81].

Struktury mogą zawierać również pola bitowe, które pozwalają na określenie rozmiaru obiektu z dokładnością do bitów[82]. Takie pola w trakcie kompilacji są umieszczane w odpowiednio dużej, adresowalnej jednostce pamięci. Jeżeli ma ona wystarczający rozmiar, by pomieścić sąsiednie pola, zostaną one w niej razem upakowane. Standard ISO C nie określa kolejności, w której przylegające do siebie pola bitowe są przechowywane w pamięci[81]. Pobieranie adresu pola bitowego jest niedozwolone[83].

Przykładowa deklaracja struktury opisującej węzeł pewnego drzewa[84]:

struct tnode {
    char *word;
    int count;
    struct tnode *left;
    struct tnode *right;
}

Typem podobnym do struktur są unie. Pozwalają one przechowywać wartości różnych typów pod tym samym adresem, z poszanowaniem ograniczeń dotyczących ich ułożenia w pamięci. Unia ma przynajmniej taki rozmiar, jak największa spośród jej składowych. Wszystkie operacje, które są dopuszczalne dla struktur, można wykonywać również na uniach[85].

Standard języka C definiuje również typy atomowe, choć stanowią one opcjonalną funkcjonalność, która nie musi być obsługiwana przez implementacje[86]. Biblioteka standardowa dostarcza funkcje pozwalające m.in. na zmianę wartości zmiennych takich typów w sposób atomowy, tj. z gwarancją, że operacja nie zostanie przerwana przez inne działanie na tej samej zmiennej[87].

W języku C dostępne są także typy danych opisujące funkcje. Zawierają one informacje o typie parametrów oraz wartości zwracanej[68]. Zmienna typu funkcyjnego, jeśli nie jest argumentem operatora pozyskania adresu &, niejawnie przekształca się we wskaźnik do funkcji[41]. Wywołania, dokonywane za pośrednictwem wskaźników nie są przez standard rozróżniane od tych zawierających wprost nazwę funkcji[88].

Aliasy typów[edytuj | edytuj kod]

W języku C dostępny jest mechanizm pozwalający na zdefiniowanie synonimów dla istniejących typów danych. Aliasowanie nie tworzy nowego typu, zatem obiekty utworzone z użyciem zarówno pierwotnej, jak i nowej nazwy mają identyczne właściwości[89].

Mechanizm ten wykorzystuje się między innymi w celu zapewnienia przenośności oprogramowania podczas wykorzystania typów zależnych od docelowej architektury. Przykładem takiego zastosowania są size_t i ptrdiff_t, pochodzące z biblioteki standardowej języka C[90]. Przechowują one liczby całkowite, lecz ich dokładny typ zależy od implementacji[91].

Inny powód, dla którego typom nadawane są nowe nazwy, to ułatwienie zrozumienia programu poprzez nadanie opisowych nazw bardziej złożonym konstrukcjom[92]. Poniższe trzy deklaracje funkcji są sobie równoważne[93]:

// fv jest aliasem dla funkcji przyjmującej parametr int i nie zwracającej żadnej wartości
typedef void fv(int);
// pfv to alias dla wskaźnika na funkcję taką jak powyżej
typedef void (*pfv)(int);

// Równoważne deklaracje:
void (*signal(int, void (*)(int)))(int);
fv *signal(int, fv *);
pfv signal(int, pfv);

Kwalifikatory typów[edytuj | edytuj kod]

Kwalifikatory typów nadają specyficzne znaczenia wyrażeniom, które są l-wartością[94]. Można je ze sobą dowolnie łączyć[94].

const
Oznacza wartość, która nie może być zmieniana[95]. Próba modyfikacji tak zdefiniowanego obiektu przez l-wartość usuwającą to ograniczenie jest zachowaniem niezdefiniowanym[96]. Obiekty zdefiniowane statycznie jako const mogą zostać umieszczone w pamięci z dostępem tylko do odczytu[97].
volatile
Oznacza, że wartość wyrażenia jest nieprzewidywalna lub może mieć nieznane efekty uboczne[98]. Jest to wskazówka dla kompilatora, aby nie dokonywał w obrębie tego wyrażenia żadnych optymalizacji[99]. W środowisku wieloprocesorowym może to oznaczać, że zmienna jest dostępna z wielu wątków równocześnie[97]. Statyczne obiekty volatile są odpowiednim wyborem przy modelowaniu układów wejścia/wyjścia mapowanego w przestrzeni adresowej procesora[97]. Próba modyfikacji tak zdefiniowanego obiektu przez l-wartość usuwającą to ograniczenie jest zachowaniem niezdefiniowanym[100].
restrict
Kwalifikator typu wskaźnikowego będący wskazówką optymalizacyjną dla kompilatora, że dostęp do wszelkich danych obiektu dokonywany jest jedynie przez podany wskaźnik[98].
_Atomic
Oznacza wartość, do której możliwy ma być dostęp za pomocą niepodzielnej instrukcji. Szczegółowy zestaw dostępnych operacji i typów danych jest zdefiniowany w dedykowanym pliku nagłówkowym <stdatomic.h>[101].
identyfikator przestrzeni adresowej
Systemy wbudowane używają procesorów, które mają wiele różnych i rozłącznych przestrzeni adresowych. Możliwe jest określanie, że obiekt ma być umieszczony w określonej przestrzeni za pomocą dedykowanych kwalifikatorów[102]. Przykładowo dla procesora Intel 8051 dostępne są kwalifikatory pamięci code, data, idata, bdata, xdata, far i pdata[103]. Natomiast kompilator C dla z/OS wspiera __callback, __far, __fdptr, __ptr32 i __ptr64[104]. Rozszerzenia dotyczące wsparcia różnych przestrzeni adresowych implementuje również kompilator GNU C na przykład __flash, __memx, __far, __ea, __seg_fs lub __seg_gs. Ich dostępność zależy od docelowego procesora, na który jest kompilowany kod[105].

Zarządzanie pamięcią[edytuj | edytuj kod]

Standard języka C gwarantuje, że na czas życia obiektu zostanie mu przydzielona pamięć. Ponadto przez cały ten czas dany obiekt będzie dostępny pod stałym adresem i będzie przechowywał ostatnio zapisaną wartość. Momenty utworzenia i zniszczenia obiektu są zależne od przypisanej mu klasy pamięci[106]. Dostęp do pamięci nie jest kontrolowany przez język[107], ale próby odczytu lub zapisu pod nieprawidłowymi adresami mogą skończyć się naruszeniami ochrony pamięci[108].

Każdy obiekt (poza polami bitowymi) składa się z ciągłej sekwencji bajtów, których kolejność i sposób kodowania wartości może zależeć od implementacji[86].

Po upłynięciu czasu życia zmiennej, wszelkie odwołania do niej prowadzą do niezdefiniowanego zachowania. Podobnie wartość wskazywana przez wskaźnik staje się nieokreślona, kiedy wskazywany obiekt kończy życie[106].

Klasy pamięci[edytuj | edytuj kod]

Deklarując obiekt, można wskazać jego klasę pamięci, która określa między innymi jego czas życia i zasięg widoczności. Zmienne lokalne, o ile nie użyto żadnego specyfikatora klasy pamięci, są deklarowane jako zmienne automatyczne[39]. Wartości niezainicjalizowanych zmiennych są niezdefiniowane i mogą mieć wartość zależną od kompilatora lub od tego, co akurat było w pamięci[109]. Są one dostępne przez cały czas wykonywania bloku, gdzie zostały zadeklarowane[e]. W przypadku rekurencyjnego wkroczenia do tego samego bloku, za każdym razem tworzona jest osobna instancja obiektu. Tę klasę pamięci można również określić jawnie słowem kluczowym auto[106].

Podobne do zmiennych automatycznych są zmienne rejestrowe. Zadeklarowanie obiektu ze słowem register sugeruje kompilatorowi, by umieścił go w pamięci o szybkim dostępie (np. rejestrze procesora[110]). Ostateczny wybór rodzaju pamięci, w której znajdzie się zmienna, należy jednak do kompilatora. Niezależnie od tego, czy obiekt zlokalizowany będzie w pamięci adresowalnej, zabronione jest pobieranie adresu zmiennej rejestrowej[111].

Innym rodzajem zmiennych są zmienne statyczne (deklarowane słowem static). Pamięć dla nich inicjalizowana jest w momencie uruchomienia programu i od tego momentu wszystkie odwołania dotyczą tego samego regionu pamięci[106]. W przypadku, gdy zmienną lokalną zadeklarowano jako statyczną, będzie ona przechowywała tę samą wartość pomiędzy różnymi wywołaniami funkcji. Z kolei statyczne zmienne zewnętrzne charakteryzują się linkowaniem wewnętrznym, co oznacza, że nie są widoczne na zewnątrz jednostki tłumaczenia, w której je zadeklarowano[110].

Obiektowi można również nadać klasę extern, która jawnie informuje, że cechuje się on linkowaniem zewnętrznym. Jest to domyślna własność zmiennych deklarowanych na zewnątrz funkcji[112]. Zmienne statyczne i zewnętrzne są inicjalizowane zerem, jeśli nie podano żadnej wartości początkowej[113].

Istnieje również klasa pamięci _Thread_local, której czas życia jest powiązany z wątkiem. Obiekty zadeklarowane w ten sposób są tworzone w momencie rozpoczęcia wątku. Dostęp pośredni do zmiennych tego rodzaju należących do innych wątków wywołuje zachowanie zależne od implementacji[106].

Formalnie, specyfikatorem klasy pamięci jest także typedef. Zalicza się go do tej grupy dla wygody, choć nie służy do deklarowania pamięci[114].

Alokacja pamięci[edytuj | edytuj kod]

Biblioteka języka C udostępnia funkcje służące do alokacji pamięci o arbitralnie wybranym rozmiarze (malloc i odmiany). Zwracają one wskaźnik do pierwszego bajtu obszaru pamięci, który można następnie rzutować na dowolny inny typ wskaźnikowy. Zarezerwowany w ten sposób zakres, w zależności od wywołanej funkcji, może być zainicjalizowany samymi zerami, lecz nie musi. Czas życia obiektów w alokowanej jawnie pamięci trwa od jej przydzielenia aż do zwolnienia za pomocą funkcji free[115].

Zastosowanie ręcznej alokacji pamięci może prowadzić do wystąpienia błędów w kodzie, wynikających np. z odwołań do wiszących wskaźnikówInformacje powiązane z artykułem „Wiszący wskaźnik” w Wikidanych, ale także przepełnienia bufora i próby powtórnej dealokacji. Obecne w programie podatności mogą zależeć od wykorzystanego algorytmu rezerwacji pamięci[116].

Przykład „Hello world”[edytuj | edytuj kod]

Kartka papieru do drukarki z odręcznie napisanym kodem w języku C. Poniżej podpis autora.
Program „Hello world” napisany odręcznie przez Briana Kernighana

Program wyświetlający na ekranie napis „Hello world” był pierwszym fragmentem kodu w języku C, umieszczonym w książce Język C[117]. Składnia kodu z pierwszego wydania tej książki odbiega od późniejszych standardów[118]. Program ten, w bardzo podobnej formie, znajdował się również w dokumencie Programming in C: A Tutorial, przygotowanym przez B. Kernighana w 1974 roku[119][120].

main()
{
    printf("hello, world");
}

Powyższy kod prawdopodobnie nie zostanie skompilowany, jeśli nie wymusi się na kompilatorze przyjęcia standardu C90. Nowsza wersja tego programu, rozumiana przez współczesne kompilatory, wygląda następująco[118]:

#include <stdio.h>

int main(void){
    printf("hello, world");
}

Pierwsza linijka tego kodu informuje preprocesor, aby dołączył w to miejsce zawartość pliku stdio.h, który wchodzi w skład biblioteki standardowej języka C[121]. Zadeklarowane w nim są procedury odpowiadające za obsługę wejścia i wyjścia, w tym printf[122]. Następnie definiowana jest funkcja main. To od niej rozpoczyna się wykonanie programu napisanego w C. Funkcja ta nie przyjmuje żadnych argumentów i zwraca wartość całkowitą. Wewnątrz nawiasów klamrowych znajduje się lista instrukcji, które zostaną wywołane po uruchomieniu programu[123].

W przykładowym programie funkcja main składa się z jednej instrukcji: wywołania printf z argumentem "hello, world". Służy ono do wyświetlenia tekstu na ekranie[121]. Mogłaby się tam znaleźć jeszcze instrukcja return, ale zgodnie ze standardem ISO C, umieszczenie jej w funkcji main jest opcjonalne. Zwrócona do systemu operacyjnego zostanie wtedy wartość 0[124]. Wartość zwracana przez funkcję main to tzw. kod wyjściaInformacje powiązane z artykułem „kod wyjścia” w Wikidanych (ang. exit status albo return code), a wartość 0 zazwyczaj oznacza udane wykonanie programu[125][126].

Zastosowania[edytuj | edytuj kod]

Zastosowania języka C

Głównym celem, który przyświecał Dennisowi Ritchiemu przy tworzeniu języka C było ułatwienie pisania oprogramowania systemowego. Potrzebny był język wysokopoziomowy, ale jednocześnie tak wydajny jak asembler[127]. Z tego też powodu C bywa nazywany „wysokopoziomowym asemblerem”[128]. Powstały w nim m.in. Unix[128] i jądro Linux[129]. W praktyce dla każdej nowej architektury język C jest pierwszym dostępnym językiem programowania poza asemblerem[130].

W latach 80. XX wieku C zdobył popularność również wśród twórców oprogramowania aplikacyjnego. Jego głównymi konkurentami były wtedy BASIC i Pascal. C miał nad obydwoma przewagę, będąc dość ściśle ustandaryzowanym i pozbawionym niezgodnych ze sobą odmian. Ponadto zapewniał w tamtym czasie najpełniejsze wsparcie dla programowania strukturalnego, pozwalając również na hermetyzację kodu[128].

Zastosowanie języka C pozwoliło części producentów oprogramowania zrezygnować ze stosowania języka asemblera[128]. W ten sposób postąpiono np. z Oracle Database w 1983 roku, co pozwoliło na osiągnięcie jego przenośności. W konsekwencji, Oracle Database 3 stało się pierwszym silnikiem relacyjnych baz danych, który można było uruchomić zarówno na komputerach typu mainframe, minikomputerach jak i komputerach osobistych[131]. W C został napisany również najpopularniejszy na świecie silnik bazodanowy, SQLite[132].

Innymi przykładami oprogramowania przygotowanego w języku C są serwer HTTP Apache[133], biblioteka kryptograficzna OpenSSL[134], a także gry Doom[135] i Quake[136].

Środowiska wykonawcze dla programów napisanych w innych językach również powstają z wykorzystaniem kodu w C. Dotyczy to np. Java Runtime Environment[137], CPythona (referencyjnej implementacji Pythona)[138] czy interpretera PHP[139]. Ponadto C bywa także stosowany jako język pośredni dla kompilatorów języków wyższego poziomu. Takie kompilatory zostały napisane m.in. dla Basica, Pythona czy Prologa[140]. Niektóre języki wymagają jednak cech, których C nie oferuje, np. rekurencji ogonowej albo wsparcia dla odśmiecania pamięci. Z tego powodu zaprojektowano m.in. C--[141].

Popularność[edytuj | edytuj kod]

Język C, przez ponad 20 lat prowadzenia rankingu TIOBE IndexInformacje powiązane z artykułem „TIOBE Index” w Wikidanych (od 2001 roku), plasował się na jednym z dwóch czołowych miejsc, trzykrotnie zdobywając miano „języka roku”[142], nadawane językowi, który odnotuje najwyższy wzrost wskaźnika rankingowego rok do roku[143]. Z kolei w PYPL – alternatywnym rankingu popularności języków programowania – liczone łącznie języki C i C++ osiągnęły w czerwcu 2022 piątą lokatę[144].

Badanie projektów open source na platformie GitHub z 2014 roku wskazało, że ok. 60% linii kodu źródłowego napisanych było w C, choć znajdowały się one jedynie w 10% przebadanych repozytoriów. Autorzy badania są zdania, że tak wysoka wartość pierwszego wskaźnika może wynikać w faktu, iż w C powstały znaczące części systemów operacyjnych, m.in. jądro Linux i jego odmiany, które należą do projektów o największej bazie kodu[3].

Według Stack Overflow Developer Survey 2022, co szósty profesjonalny programista zna język C. Większość respondentów (60%) oceniła go jednak jako „przerażający” (w dwustopniowej skali, drugą opcją było „uwielbiany”). Natomiast 4,3% osób zadeklarowało, że chce rozpocząć pracę z tym językiem[145].

Wpływ[edytuj | edytuj kod]

Popularność i szerokie zastosowanie języka C ma bezpośredni wpływ na składnię lub semantykę innych języków programowania[130]. Przede wszystkim najbardziej podobnym i kompatybilnym jest język C++, który powstawał jako rozszerzenie „C z klasami”[146]. Inne języki wykazujące podobieństwa do składni C to między innymi C#[147], csh[148], D[149], Go[150], IDL[151], Java[152] (w zasadzie do C++[153]), JavaScript[154], Objective-C[155], OpenCL[156], OpenGL[157], PAWN[158], Perl[159], PHP[160], tudzież Swift[161].

Krytyka[edytuj | edytuj kod]

C charakteryzuje się słabym typowaniem. Jego specyfikacja pozwala na rzutowanie typów wskaźnikowych na dowolne inne typy wskaźnikowe. W konsekwencji dowolny region pamięci może być traktowany tak, jakby zawierał dane dowolnego typu. Jednocześnie narzędzia wspomagające pisanie kodu nie są w stanie sprawdzić, czy konwersja typów jest sensowna[162]. W C jest ponadto dozwolone przypisanie wartości do zmiennej innego typu. Jako przykład słabości wynikającej ze słabego typowania, I. Pohl i D. Edelson podali typową implementację funkcji, zmieniającej małe litery na wielkie. Wykorzystuje ona operacje arytmetyczne na liczbach całkowitych oraz zmiennych typu char, mimo działania – na poziomie koncepcji – wyłącznie w dziedzinie znakowej[44]. Powszechne wykorzystanie wskaźników, pozwalających na niskopoziomowy dostęp do pamięci jest czynnikiem osłabiającym bezpieczeństwo programów. Niejawna konwersja typów całkowitoliczbowych (zmiana szerokości oraz możliwości przechowywania liczb ujemnych) oraz ciche przekroczenia zakresu wartości również należą do częstych przyczyn błędów oprogramowania, objawiających się w szczególności tam, gdzie dokonywane są operacje pamięciowe i prowadzą zwykle do przepełnienia buforów[107].

Mimo deklarowania tablic jako składające się z określonej liczby elementów, nie istnieje mechanizm sprawdzający, czy programista odwołuje się do elementu wewnątrz tablicy[163]; co więcej, dozwolone jest używanie ujemnych indeksów, aby odwołać się do obiektów leżących w pamięci przed zerowym[164]. Przeszkadza to w implementacji np. odśmiecania pamięci, ale też stanowi powszechne źródło trudnych do wykrycia błędów w oprogramowaniu[163]. Możliwość zapisu danych poza tablicę bywa wykorzystywana jako wektor atakuInformacje powiązane z artykułem „cyberatak” w Wikidanych, prowadzącego do uzyskania kontroli nad systemem komputerowym poprzez wstrzyknięcie do programu odpowiednio spreparowanych poleceń lub zmianę stanu innych zmiennych[165].

Wielowymiarowe tablice są w rzeczywistości tablicami jednowymiarowymi, co w przeszłości utrudniało pisanie funkcji wykonujących np. obliczenia macierzowe[166][163]. W pierwotnej wersji standardu język C nie wspierał obsługi tablic o zmiennej (to znaczy ustalanej dopiero w momencie działania programu) liczbie elementów[167], w tym przekazywania takich tablic jako argumentów funkcji. Dlatego do adresowania np. elementów macierzy wykorzystywano pomocniczą tablicę wskaźników do pierwszych elementów każdego wiersza[166].

Innym problemem, który podnoszono jest niekonsekwencja twórców standardu, objawiająca się w określeniach void i void*. Pierwsze z nich oznacza brak wartości. Zatem zgodnie z logiką konstruowania typów, ten drugi powinien być wskaźnikiem na wartość pustą. W rzeczywistości jednak jest to wskaźnik na wartość dowolnego typu. Jeszcze inne zastosowanie słowa void, niezwiązane z desygnowaniem typu, to wskazanie, że funkcja nie przyjmuje żadnych argumentów[163].

Z perspektywy czasu niektóre decyzje dotyczące składni okazały się nieoptymalne. Jedną z nich jest niższy priorytet operatorów bitowych niż porównania, co wymusza pisanie konstrukcji takich jak (a & mask) == b, które bez nawiasów działałyby niezgodnie z intencją programisty[4]. Inną z częściej spotykanych pułapek jest zamienienie operatorów porównania (==) i przypisania (=). Kod napisany w ten sposób pozostaje poprawny składniowo, więc pomyłka nie zostanie zgłoszona przez kompilator. Innym operatorem, który utrudnia zrozumienie programu jest przecinek, pozwalający na wykonanie kilku wyrażeń w jednej instrukcji. Ten sam symbol oddziela od siebie np. argumenty funkcji[44].

Sama składnia deklarowania typów pochodnych również może konfundować. Założenie, że sposób deklaracji odpowiada sposobowi użycia zmiennej danego typu, spowodowało, że trzeba je czytać od środka na zewnątrz. Jest to konwencja trudna do uchwycenia przez wiele osób. Tego mankamentu dałoby się uniknąć, gdyby operator dereferencji był przyrostkowym, a nie przedrostkowym, jak to ma miejsce w C[4].

Cechy języka, krytykowane jako trudne do odczytania lub zrozumienia, bywają również wykorzystywane do celowego zaciemniania kodu, czego skrajnym przypadkiem są programy zgłaszane do konkursu IOCCC[168].

Standard języka C opisuje wiele sytuacji, dla których zachowanie jest niezdefiniowaneInformacje powiązane z artykułem „zachowanie niezdefiniowane” w Wikidanych lub nieokreśloneInformacje powiązane z artykułem „zachowanie nieokreślone” w Wikidanych. Daje to pewne pole manewru na różne optymalizacje w zależności od platformy sprzętowej. W rezultacie ten sam kod skompilowany na różnych kompilatorach lub z różnymi opcjami kompilacji może się inaczej zachowywać[169]. W szczególności standard C nie określa, w jaki sposób przechowywane są w pamięci wielobajtowe wartości skalarne. Większość programów polega jedynie na domyślnym zachowaniu zapewnionym przez ABI. Nie zapewnia ono jednak przenośności między różnymi platformami[170]. Jest to jeden z głównych powodów nieprzenaszalności kodu, który ujawnia się podczas wymiany danych poprzez pamięć współdzieloną, masową lub ich transmisję[171]. Jedną z naczelnych zasad ducha programowania w C jest tworzenie wydajnego kodu nawet za cenę jego przenośności[172].

Niezainicjowana zmiennaInformacje powiązane z artykułem „Niezainicjowana zmienna” w Wikidanych to problem, który dotyczy wielu języków programowania[173]. Błąd ten powstaje z winy programisty[174]. Jest on trudny do wykrycia, gdyż taki program może się zupełnie inaczej zachowywać w środowisku diagnostycznym pod kontrolą debuggera niż w środowisku produkcyjnym[175] lub wręcz w kolejnych wykonaniach przy takich samych danych wejściowych[176]. Kompilator języka jedynie rezerwuje dla zmiennej obszar w pamięci, a jej wartość jest taka jaka wynika ze stanu bitów, która się w tej pamięci aktualnie znajduje[177]. Kompilator często ostrzega o próbie dostępu do niezainicjowanej zmiennej[178].

Uwagi[edytuj | edytuj kod]

  1. na przykład #pragma once
  2. a b c d e f g Możliwe jest również stosowanie skróconej nazwy, bez członu int[64].
  3. Operator indeksowania tablic tab[i] jest z definicji równoważny wyrażeniu *(tab+i), a zatem indeksowanie jest przemienne. Konsekwencją tego faktu jest że zapisy tab[i] oraz i[tab] są równoważne i odnoszą się do i-tego elementu tablicy tab[71].
  4. Oznacza to, że dodanie liczby n do wskaźnika ptr na typ T zwróci nowy wskaźnik o adresie ptr + n * sizeof(T). Podobnie, odjęcie od siebie dwóch wskaźników, zwróci różnicę indeksów tabeli, odpowiadających wskazywanym elementom.
  5. W przypadku, gdy obiekt jest tablicą o zmiennej długości, jego czas życia rozpoczyna się w momencie napotkania deklaracji, a nie wejścia do bloku.

Przypisy[edytuj | edytuj kod]

  1. a b ISO/IEC 9899:2018, ISO, czerwiec 2018 [dostęp 2022-06-29] (ang.).
  2. David Keaton, WG 14 N 2021 -- Preliminary C2x Charter, Open Standards, 12 marca 2016 [dostęp 2022-07-15] (ang.).
  3. a b Tegawendé F. Bissyandé i inni, Popularity, Interoperability, and Impact of Programming Languages in 100,000 Open Source Projects, 37th Annual International Computer Software & Applications Conference (COMPSAC 2013), Kioto, lipiec 2013 [dostęp 2022-06-24] (ang.).
  4. a b c d e f g h i j k l m n o p q r Dennis M. Ritchie, The development of the C language, „ACM SIGPLAN Notices”, 28 (3), 1993, s. 201–208, DOI10.1145/155360.155580, ISSN 0362-1340 [dostęp 2022-01-15] [zarchiwizowane z adresu 2022-01-07] (ang.).
  5. M. Douglas McIlroy, A Research UNIX Reader: Annotated Excerpts from the Programmer’s Manual, 1971-1986, s. 10 [dostęp 2022-01-15] [zarchiwizowane z adresu 2021-11-01] (ang.).
  6. a b Stephen C. Johnson, Dennis M. Ritchie, Portability of C Programs and the UNIX System, s. 4 [dostęp 2022-01-15] [zarchiwizowane z adresu 2021-12-18] (ang.).
  7. Kernighan i Ritchie 2002 ↓, s. 13.
  8. a b c d Gabor Kovesdan, c78(7) manual page [dostęp 2022-01-15] [zarchiwizowane z adresu 2021-08-14] (ang.).
  9. Dennis M. Ritchie, Brian Kernighan, The C Programming Language, wyd. 1, Englewood Cliffs: Prentice-Hall, 1978, s. 34, ISBN 0-13-110163-3 (ang.).
  10. Dennis M. Ritchie, Brian Kernighan, The C Programming Language, wyd. 1, Englewood Cliffs: Prentice-Hall, 1978, s. 143, ISBN 0-13-110163-3 (ang.).
  11. Dennis M. Ritchie, Brian Kernighan, The C Programming Language, wyd. 1, Englewood Cliffs: Prentice-Hall, 1978, s. 121, ISBN 0-13-110163-3 (ang.).
  12. Bjarne Stroustrup, A history of C++, „ACM SIGPLAN Notices”, 28 (3), 1993, DOI10.1145/154766.155375 [dostęp 2022-07-24] (ang.).
  13. a b Mark Gass, Using the New Features in ANSI C [dostęp 2022-01-15] (ang.).
  14. Rationale for the ANSI C Programing Language, Sillicon Press, 1990, s. 52, ISBN 0-929306-07-4.
  15. David Lindnerr, Finnbarr P. Murphy, ISO C Amendment 1 (MSE) [dostęp 2022-06-29] (ang.).
  16. a b ISO/IEC 9899:1990/Amendment 1:1995, 1995, s. 1, 2, 7 (ang.).
  17. ISO/IEC 9899:1990, 1990, s. 10–11 (ang.).
  18. a b Deepu Benson, Different C Standards: The Story of C, Open Source For You, 17 kwietnia 2017 [dostęp 2022-06-28] (ang.).
  19. a b c Shrirang A. Kulkarni, C99 features in GCC on Fedora, Fedora Magazine, 9 grudnia 2016 [dostęp 2022-06-28] (ang.).
  20. a b c ISO/IEC 9899:1999, 1999, s. 160, 170, 253 (ang.).
  21. a b c Danny Kalev, C11: A New C Standard Aiming at Safer Programming, SmartBear.com, 25 czerwca 2012 [dostęp 2022-06-29] (ang.).
  22. a b Elnar Dakeshov, C11 and C17 Standard Support Arriving in MSVC, C++ Team Blog, 14 września 2020 [dostęp 2022-06-29] (ang.).
  23. a b c Author Jens Gustedt, C17, Jens Gustedt’s Blog, 17 kwietnia 2018 [dostęp 2022-06-29] (ang.).
  24. The Current C Programming Language Standard – ISO/IEC 9899:2018 (C18) – ANSI Blog, The ANSI Blog, 13 listopada 2018 [dostęp 2022-06-29] (ang.).
  25. ISO/IEC9899:2017 ↓, s. i.
  26. 1.6. White Space, [w:] The GNU C Reference Manual, GNU [dostęp 2022-03-13].
  27. a b ISO/IEC9899:2017 ↓, s. 9.
  28. a b ISO/IEC9899:2017 ↓, s. 28.
  29. a b ISO/IEC9899:2017 ↓, s. 43.
  30. a b ISO/IEC9899:2017 ↓, s. 20.
  31. ISO/IEC9899:2017 ↓, s. 44.
  32. ISO/IEC9899:2017 ↓, §7.1.3 Reserved identifiers, s. 132.
  33. a b c ISO/IEC9899:2017 ↓, s. 29.
  34. a b ISO/IEC9899:2017 ↓, s. 55.
  35. ISO/IEC9899:2017 ↓, s. 61.
  36. a b ISO/IEC9899:2017 ↓, s. 12.
  37. ISO/IEC9899:2017 ↓, s. 366.
  38. ISO/IEC9899:2017 ↓, s. 57–75.
  39. a b Kernighan i Ritchie 2002 ↓, s. 256.
  40. ISO/IEC9899:2017 ↓, s. 5.
  41. a b c d ISO/IEC9899:2017 ↓, s. 40.
  42. ISO/IEC9899:2017 ↓, s. 78–80.
  43. 5. Functions, [w:] The GNU C Reference Manual, GNU [dostęp 2022-03-13] (ang.).
  44. a b c Ira Pohl, Daniel Edelson, A to Z: C language shortcomings, „Computer Languages”, 13 (2), 1988, s. 51–64, DOI10.1016/0096-0551(88)90009-4 (ang.).
  45. Kalsoom Bibi, Function Overloading in C [dostęp 2022-03-13] (ang.).
  46. 5.5 Variable Length Parameter Lists, [w:] The GNU C Reference Manual, GNU [dostęp 2022-03-13] (ang.).
  47. ISO/IEC9899:2017 ↓, s. 108.
  48. ISO/IEC9899:2017 ↓, s. 109–110.
  49. ISO/IEC9899:2017 ↓, s. 110–112.
  50. ISO/IEC9899:2017 ↓, s. 118.
  51. ISO/IEC9899:2017 ↓, s. 118–121.
  52. Kernighan i Ritchie 2002 ↓, s. 305.
  53. ISO/IEC9899:2017 ↓, s. 127.
  54. ISO/IEC9899:2017 ↓, s. 54.
  55. Kernighan i Ritchie 2002 ↓, s. 60.
  56. Kernighan i Ritchie 2002 ↓, s. 257–258.
  57. Kernighan i Ritchie 2002 ↓, s. 262.
  58. a b c Kernighan i Ritchie 2002 ↓, s. 258.
  59. a b c Kernighan i Ritchie 2002 ↓, s. 61.
  60. Kernighan i Ritchie 2002 ↓, s. 61–62.
  61. Kernighan i Ritchie 2002 ↓, s. 257.
  62. ISO/IEC9899:2017 ↓, s. 31.
  63. ISO/IEC9899:2017 ↓, s. 20–22.
  64. ISO/IEC9899:2017 ↓, s. 80.
  65. Kernighan i Ritchie 2002 ↓, s. 62.
  66. ISO/IEC9899:2017 ↓, s. 24–25.
  67. Kernighan i Ritchie 2002 ↓, s. 65.
  68. a b ISO/IEC9899:2017 ↓, s. 32.
  69. Kernighan i Ritchie 2002 ↓, s. 136.
  70. Kernighan i Ritchie 2002 ↓, s. 45.
  71. Kernighan i Ritchie 2002 ↓, s. 288.
  72. Kernighan i Ritchie 2002 ↓, s. 138.
  73. Kernighan i Ritchie 2002 ↓, s. 130–131.
  74. a b Kernighan i Ritchie 2002 ↓, s. 141–143.
  75. ISO/IEC9899:2017 ↓, s. 67, 69.
  76. ISO/IEC9899:2017 ↓, s. 67.
  77. Kernighan i Ritchie 2002 ↓, s. 173–175.
  78. Kernighan i Ritchie 2002 ↓, s. 174.
  79. ISO/IEC9899:2017 ↓, s. 81.
  80. Kernighan i Ritchie 2002 ↓, s. 175–176.
  81. a b ISO/IEC9899:2017 ↓, s. 82.
  82. Kernighan i Ritchie 2002 ↓, s. 200.
  83. ISO/IEC9899:2017 ↓, s. 64.
  84. Kernighan i Ritchie 2002 ↓, s. 188.
  85. Kernighan i Ritchie 2002 ↓, s. 198–200.
  86. a b ISO/IEC9899:2017 ↓, s. 33.
  87. ISO/IEC9899:2017 ↓, s. 206–209.
  88. ISO/IEC9899:2017 ↓, s. 58.
  89. Kernighan i Ritchie 2002 ↓, s. 197.
  90. Kernighan i Ritchie 2002 ↓, s. 197–198.
  91. Kernighan i Ritchie 2002 ↓, s. 270–271.
  92. Kernighan i Ritchie 2002 ↓, s. 198.
  93. ISO/IEC9899:2017 ↓, s. 100.
  94. a b ISO/IEC9899:2017 ↓, s. 87.
  95. The const type qualifier, [w:] IBM docs [online], ibm.com [dostęp 2022-07-10].
  96. ISO/IEC9899:2017 ↓, s. 87, 408, 473.
  97. a b c Rationale for the ANSI C Programing Language, Sillicon Press, 1990, s. 53, ISBN 0-929306-07-4.
  98. a b ISO/IEC9899:2017 ↓, s. 88.
  99. The volatile type qualifier, [w:] IBM docs [online], ibm.com [dostęp 2022-07-10].
  100. ISO/IEC9899:2017 ↓, s. 87–88.
  101. ISO/IEC9899:2017 ↓, s. 200–209.
  102. Named address spaces and named-register storage classes, [w:] Programming languages – C – Extensions to support embedded processors, wyd. 2, 15 czerwca 2008, s. 37, 38, ISO/IEC TR 18037:2008(E).
  103. Memory Types, [w:] Cx51 User’s Guide [online], keil.com [dostęp 2022-07-10] (ang.).
  104. Type qualifiers, [w:] IBM Documentation [online], ibm.com [dostęp 2022-07-10] (ang.).
  105. Named Address Spaces, [w:] Using the GNU Compiler Collection [online], gcc.gnu.org [dostęp 2022-07-10].
  106. a b c d e ISO/IEC9899:2017 ↓, s. 30.
  107. a b Periklis Akritidis, Practical memory safety for C, „Technical Report”, 798, Cambridge: University of Cambridge Department of Computer Science and Technology, czerwiec 2011, s. 15, 24, ISSN 1476-2986 [dostęp 2022-07-24] (ang.).
  108. Identify what's causing segmentation faults (segfaults), University Information Technology Services – Indiana University [dostęp 2022-08-21] (ang.).
  109. 2 Data Types, [w:] The GNU C Reference Manual, GNU [dostęp 2022-08-20] (ang.).
  110. a b Kernighan i Ritchie 2002 ↓, s. 119.
  111. ISO/IEC9899:2017 ↓, s. 79.
  112. Kernighan i Ritchie 2002 ↓, s. 304.
  113. ISO/IEC9899:2017 ↓, s. 115.
  114. Kernighan i Ritchie 2002 ↓, s. 278.
  115. ISO/IEC9899:2017 ↓, s. 253–254.
  116. Yves Younan i inni, Improving memory management security for C and C++, „International Journal of Secure Software Engineerin”, 1 (2), 2010, DOI10.4018/jsse.2010040104 [dostęp 2022-07-24] (ang.).
  117. Dennis M. Ritchie, Brian Kernighan, The C Programming Language, wyd. 1, Englewood Cliffs: Prentice-Hall, 1978, s. 6, ISBN 0-13-110163-3 (ang.).
  118. a b C Language Tutorial => Original „Hello, World!” in K&R C, riptutorial.com [dostęp 2022-04-12].
  119. Brian W. Kernighan, Programming in C: A Tutorial, Bell Laboratories, 1974, s. 1 [dostęp 2022-04-12] [zarchiwizowane z adresu 2022-03-22] (ang.).
  120. Dennis M. Ritchie, C Reference Manual, Bell Telephone Laboratories, s. 25 [dostęp 2022-04-12] [zarchiwizowane z adresu 2022-04-12] (ang.).
  121. a b Kernighan i Ritchie 2002 ↓, s. 25.
  122. Kernighan i Ritchie 2002 ↓, s. 322–325.
  123. Kernighan i Ritchie 2002 ↓, s. 24–25.
  124. ISO/IEC9899:2017 ↓, s. 11.
  125. 5.7 The main Function, [w:] The GNU C Reference Manual, GNU [dostęp 2022-03-13].
  126. Piotr Szawdyński, [lekcja] Podstawy programowania w C++, cpp0x.pl [dostęp 2022-08-20].
  127. P. Fazio, K. Gowri, Structural analysis software and the C programming language, „Computers & Structures”, 25 (3), 1987, s. 463, DOI10.1016/0045-7949(87)90138-6 (ang.).
  128. a b c d Russel Jones, The C programming language: Popularity grows for the high-level assembly language, „Data Processing”, 27 (10), 1985, s. 35–38, DOI10.1016/0011-684X(85)90032-2 (ang.).
  129. Programming Language – The Linux Kernel documentation, www.kernel.org [dostęp 2022-06-10] (ang.).
  130. a b Robert Chatley, Alastair Donaldson, Alan Mycroft, The next 7000 programming languages, §2.2 Systems programming and the rise of C, DOI10.1007/978-3-319-91908-9_15.
  131. Brief History of Oracle Database, [w:] Lance Ashdown, Donna Keesling, Tom Kyte, Introduction to Oracle Database, Oracle Help Center [dostęp 2022-06-10] (ang.).
  132. SQLite Home Page, www.sqlite.org [dostęp 2022-06-10] (ang.).
  133. Apache Software Foundation, apache/httpd, GitHub [dostęp 2022-06-10] (ang.).
  134. OpenSSL Project, openssl/openssl: TLS/SSL and crypto library, GitHub [dostęp 2022-06-10] (ang.).
  135. Paul C. Schuytema, The Lighter Side Of Doom, „Computer Gaming World”, 121, sierpień 1994, s. 140, 142 (ang.).
  136. id-Software, id-Software/Quake: Quake GPL Source Release, GitHub [dostęp 2022-06-10] (ang.).
  137. The Java(tm) Language: An Overview, web.archive.org, 22 lutego 2008 [dostęp 2022-06-10] [zarchiwizowane z adresu 2008-02-22] (ang.).
  138. Python Software Foundation, python/cpython: The Python programming language, GitHub [dostęp 2022-06-10] (ang.).
  139. The PHP Group, php/php-src: The PHP Interpreter, GitHub [dostęp 2022-06-10] (ang.).
  140. D. Bohdan, Compilers targeting C, GitHub, 30 czerwca 2021 [dostęp 2022-06-10] (ang.).
  141. Simon Peyton Jones, Thomas Nordin, Dino Oliva, C--: A portable assembly language, „Implementation of Functional Languages”, 1997, DOI10.1007/BFb0055421 (ang.).
  142. C: TIOBE Index, TIOBE [dostęp 2022-06-13] (ang.).
  143. Programming Language Hall of Fame, [w:] TIOBE Index, TIOBE [dostęp 2022-06-13] (ang.).
  144. PYPL PopularitY of Programming Language index, pypl.github.io [dostęp 2022-06-13] [zarchiwizowane z adresu 2022-06-11] (ang.).
  145. Technology, [w:] Stack Overflow Developer Survey 2022, Stack Overflow [dostęp 2022-06-22] (ang.).
  146. Bjarne Stroustrup, A History of C++: 1979−1991, DOI10.1145/154766.155375 [dostęp 2022-08-13].
  147. Ian Chivers, Essential C# fast, Springer, 2003, s. 4, DOI10.1007/978-1-4471-0075-1, ISSN 1439-975-X, Cytat: In terms of syntax, it belongs in the same family of programming languages as C, C++ and Java.
  148. Chuck Easttom, System Forensics, Investigation and Response, Jones & Bartlett Publishers, 2013, s. 188, ISBN 1-284-03108-X, Cytat: it uses very C-like syntax.
  149. Walter Bright, Andrei Alexandrescu, Michael Parker, Origins of the D programming language, „Proceedings of the ACM on Programming Languages”, 4 (HOPL), 2020, 73:18, DOI10.1145/3386323, Cytat: D intentionally looks very much like C and C++.
  150. Dušan Stojanović, Building Server-side and Microservices with Go, s. 10, Cytat: Sytactically, Go is similar to C, but many "features" are borrowed from other languages.
  151. Martin Gudgin, Essential IDL: Interface Design for COM, Addison-Wesley, 2001, s. 6, ISBN 0-201-61595-9, Cytat: IDL has syntax based on the C programming language.
  152. Dhiraj Kumar Baraik, Modern JAVA : Functional Programming, 2021, s. 13, Cytat: Its syntax is similar to C and C++.
  153. Autorzy David Reilly, Michael Reilly, Java Network Programming and Distributed Computing, Addison-Wesley Professional, 2002, s. 28, ISBN 0-201-71037-4, Cytat: oryginally modified C++ compiler.
  154. Aaron Gustafson, Introduction to JavaScript, [w:] Jennifer Niederst Robbins, Web Design in a Nutshell: A Desktop Quick Reference, O'Reilly Media, 2006, s. 465, ISBN 1-4493-7909-5, Cytat: similar to the C programming language and share similar syntax.
  155. Andrew M. Duncan, Objective-C Pocket Reference, O'Reilly Media, 2002, s. 1, ISBN 0-596-55219-X, Cytat: Objective-C uses C syntax.
  156. Unnikrishnan Cheramangalath, Rupesh Nasre, Y.N. Srikant, Distributed Graph Analytics: Programming, Languages, and Their Compilation, Springer Nature, 2020, s. 14, ISBN 3-030-41886-3, Cytat: has C-like syntax.
  157. Dan Ginsburg i inni, OpenGL ES 3.0 Programming Guide, wyd. 2, Addison-Wesley Professional, 2014, s. 98, ISBN 0-13-344012-5, Cytat: the syntax bears great similarity to that seen in the C programming language.
  158. Jason Gregory, Game Engine Architecture, §16.9.3.5 Pawn/Small/Small-C, ISBN 1-351-97427-0, Cytat: C-like scripting language.
  159. Adam McDaniel, Perl and Apache: Your visual blueprint for developing dynamic Web content, John Wiley & Sons, 2010, s. 3, ISBN 0-470-94438-2, Cytat: The Perl programming language uses a syntax structure that is very similar to C in design.
  160. K.L. JAMES, THE INTERNET: A USER’S GUIDE, wyd. 2, PHI Learning, 2010, s. 210, ISBN 81-203-4029-9, Cytat: Syntax of PHP language is similar to C or C++.
  161. Gulsun Kurubacak, Hakan Altinpulluk (red.), Mobile Technologies and Augmented Reality in Open Education, IGI Global, 2017, s. 128, ISBN 1-5225-2111-9, Cytat: The swift script uses a C-like syntax to describe data, application components, invocation of application components, and the data flow among the invocations.
  162. Satish Chandra, Thomas Reps, Physical type checking for C, New York, NY, USA: Association for Computing Machinery, 1 września 1999, s. 66, DOI10.1145/316158.316183, ISBN 978-1-58113-137-6 [dostęp 2022-06-13] (ang.).
  163. a b c d Generic C Criticisms, [w:] Ian Joyner, C++??: A Critique of C++, wyd. 3, grudzień 1996 [dostęp 2022-06-15] [zarchiwizowane z adresu 2000-08-23].
  164. Kernighan i Ritchie 2002 ↓, s. 139.
  165. Marek Wrona, Niebezpieczeństwo komputerowe, Warszawa: Wydaw. RM, [cop. 2000], s. 40-46, ISBN 83-7243-076-4, OCLC 749501645 [dostęp 2022-08-16].
  166. a b William H. Press i inni, Numerical Recipes in C: The Art of Scientific Computing, wyd. 2, Cambridge: Cambridge University Press, 1992, s. 22, ISBN 0-521-43108-5 (ang.).
  167. ISO/IEC9899:2017 ↓, s. xv.
  168. Dan Gopstein i inni, Understanding misunderstandings in source code, ESEC/FSE 2017: Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, Nowy Jork: Association for Computing Machinery, 21 sierpnia 2017, s. 129–139, DOI10.1145/3106237.3106264, ISBN 978-1-4503-5105-8 (ang.).
  169. Robert C. Seacord, Effective C: An Introduction to Proffesional C Programming, 2020, xxv, ISBN 978-1-71850-104-1, LCCN 2020017147.
  170. David Delmas, Abdelraouf Ouadjaout, Antoine Miné, Static Analysis of Endian Portability by Abstract Interpretation, [w:] Cezara Drăgoi, Suvam Mukherjee, Kedar Namjoshi (red.), Static Analysis, „Lecture notes in computer science”, 12913, 28th International Symposium, SAS 2021, Chicago, IL, USA, October 17–19, 2021, Proceedings, 2021, s. 103, DOI10.1007/978-3-030-88806-0_5, ISBN 978-3-030-88805-3, ISSN 0302-9743.
  171. Max Domeika, Software Development for Embedded Multi-core Systems, 2008, s. 95, ISBN 978-0-7506-8539-9.
  172. Rationale for the ANSI C Programing Language, Sillicon Press, 1990, s. 3, ISBN 0-929306-07-4, Cytat: Make it fast, even if it is not guaranteed to be portable.
  173. Hubertus B. Keller, Erhard Plödereder (red.), Reliable Software Technologies Ada-Europe 2000: 5th Ada-Europe International Conference Potsdam, Germany, June 26-30, 2000, Proceedings, Springer, 2006, s. 38.
  174. Yung-Hsiang Lu, Intermediate C Programming, CRC Press, 2015, s. 36, ISBN 1-4987-1164-2.
  175. Andreas Zeller, Why Programs Fail: A Guide to Systematic Debugging, Elsevier, 2009, s. 89, ISBN 0-08-092300-3.
  176. Sartaj Sahni, Robert F. Cmelik, Bob Cmelik, Software Development in C, Silicon Press, 1995, s. 164, ISBN 0-929306-16-3.
  177. Randall Hyde, Write Great Code, Vol. 2: Thinking Low-Level, Writing High-Level, No Starch Press, 2004, s. 336, ISBN 1-59327-065-8.
  178. Robert C. Seacord, The CERT® C Coding Standard, Second Edition: 98 Rules for Developing Safe, Reliable, and Secure Systems, wyd. 2, Addison-Wesley Professional, 2014, s. 56, ISBN 0-13-380529-8.

Bibliografia[edytuj | edytuj kod]

Linki zewnętrzne[edytuj | edytuj kod]