Ha a C nyelvet jellemezni kellene, akkor a bonyolult szó, ami a legtöbbünknek eszébe jut. Ez a bonyolultság azonban nem abból következik, hogy rosszul van megtervezve a nyelv, hanem abból, hogy nagyon gépközeli és olyan tudásra épít, ami nem közvetlen módon kapcsolódik magához a programozási nyelvhez.
Azonban a C még sokáig velünk marad. Nem azért, mert nincs jobb nála. Szimplán azért, mert mióta megszületett több tíz, vagy akár több száz millió sor kód született ebben a nyelvben és ezek egy részét még a mai napig használjuk nap mint nap. Ezeket a kódokat pedig karban kell tartani valakinek. Valószínűleg ezen sorok olvasása közben átfut az olvasó fején a gondolat, hogy „De nem nekem!”, ami rendben is van. Valószínűleg az idő múlásával a C nyelv is olyan lesz, mint a Cobol: háttérbe szorul új fejlesztések során, de sosem fog végleg eltűnni.
De álljunk meg egy pillanatra, mert véletlenül sem az szeretném sugallni, hogy az egész könyv üzenete az, hogy a C nyelvet megtanulni és a könyvet felesleges volt elolvasni, mert kihalófélben lévő valamiről beszélek.
A C nyelvet azért kell ismerni, mert túlnőtt egy egyszerű programozási nyelven. Egyfajta protokollá nőtte ki magát. Ahhoz, hogy egy új programozási nyelv komolyan vehető legyen, lehetőséget kell biztosítania arra, hogy interakcióba lépjünk az operációs rendszerrel valamilyen módon. Ez pedig API hívásokkal történik, amik ha tetszik, ha nem C függvények C hívási konvenciókkal és a C nyelv típusrendszerét követve.
Ez annak köszönhető, hogy a legtöbb operációs rendszer C-ben lett írva, illetve a C ABI (Application Binary Interface, egy interfész, amely meghatározza, hogyan kommunikál egy futtatható program vagy könyvtár az operációs rendszerrel vagy más programokkal bináris szinten) kellően egyszerű és sokoldalú ahhoz, hogy bármilyen nyelvből használható legyen.
Egy ilyen ABI-t nem egyszerű kitalálni és stabilizálni. Jó példa erre a Rust nyelv, amit sokan a C utódjának tekintenek, mert lehetővé teszi alacsony szintű programok fejlesztését, de memória biztonságos. A nyelv 2015 óta létezik, de a könyv írásának pillanatában sem rendelkezik stabil ABI interfésszel. Ennek következménye az, hogy egy Rust programok esetén nincsenek osztálykönyvtárak, amelyekből a kód csak úgy meghívható lenne. Minden Rust (https://www.rust-lang.org/) program fordításakor minden általa használt könyvtárt forráskódból le kell fordítani, ami hosszú fordítási időket generál.
De mit is jelent az, hogy egy nyelv memória szempontjából biztonságos és miért fontos ez? Mint láthattuk, a C abszolút nem ellenőrzi tömbök esetén, hogy egyáltalán létező indexet szeretnénk-e kivenni, illetve a mutatók sokoldalúságának egyik oka, hogy ha nem megfelelő helyre mutatunk velük, akkor megjósolhatatlan, hogy mi fog történni. Ez egészen addig nem gond, amíg a gépek nincsenek hálózatra kötve és nem fogadnak egymástól adatokat.
Azonban amint az internet és a hálózatok előkerülnek, problémás lesz a dolog, mert egy nem megfelelően elvégzett fájl vagy szöveg beolvasás felülírhatja a programunk memóriaterületét. Ha pedig ez támadó szándékkal történik és a felülírásban használt adat egy tényleges kód, akkor a futó programunk olyan kódot fog végrehajtani, amit nem mi írtunk.
Ez minimum problémás tud lenni biztonsági szempontból. Éppen ezért az utóbbi időben alacsony szintű nyelvek esetén a memóriabiztonság kérdése egyre fontosabbá vált és a jövőben még fontosabb lesz.
A C nyelv utódjának leginkább a Zig nyelv (https://ziglang.org) tekinthető, ami kompatibilis a meglévő C/C++ kódbázisokkal.
De mit érdemes annak tennie, aki a C nyelv tanulásánál szeretne maradni? A standard könyvtár funkcióin és lehetőségeink kívül érdemes mindenképpen megismerkedni az adott operációs rendszer API lehetőségeivel. Windows esetén ez a Windows API, amit a Microsoft elég jól dokumentált a saját weboldalán. (https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-api-list)
Linux és Unix-szerű rendszerek esetén ez a POSIX (Portable Operating System Interface ) API, amit még 1988-ban azért dolgoztak ki, hogy a Unix-szerű rendszerek egymással kompatibilisek tudjanak maradni. Ez az API nem fed le azonban mindent. Minden Unix rendszernek (BSD, Linux, Mac) vannak saját specifikus API hívásai, amelyek nem léteznek, vagy más néven léteznek az adott operácíós rendszeren.