C neboli céčko, je a ještě dlouho bude zřejmě nejpoužívanějším programovacím jazykem této planety. Důvody jsou k tomu dva.
Tím prvním je přenositelnost na úrovni zdrojového kódu. Teď se asi mnoho lidí ironicky ušklíblo a někteří čtenáři již ťukají ve svém oblíbeném mailovači zprávu, ať se podívám na Javu (Perl, Python, …), pokud chci vědět, jak má přenositelnost vypadat. Vím, že napsat program v C tak, aby byl plně přenositelný, je obrovsky složité, ale byl bych rád, aby se nezapomínalo, že céčko je v pořadí hned nad assemblerem. Je to v podstatě nízkoúrovňový jazyk a na této úrovni je samozřejmě kompatibilita platforem prakticky nulová, stačí už jenom rozdílné délky základních typů (někde je int 32bitový, jinde 16bitový), endianita a podobně. Nic to však nemění na tom, že je jazyk C pevně definovaný normou a kdyby to nekomplikovali výrobci kompilátorů nedodržováním standardů, bylo by možné naprostou většinu problémů řešit prostředky jazyka (místo abych počítal s tím, že int má 4 bajty, použiju zkrátka sizeof(int)), což ovšem klade zvýšené nároky na kázeň programátora.
Druhým důvodem oblíbenosti jazyka C je jeho flexibilita a možnosti. Konec konců, i zmiňovaná Java, Perl či další jazyky, respektive jejich kompilátory nebo interpretry jsou napsané v céčku. Programátor není omezován high-level obalem, což umožňuje vysokou pružnost a efektivitu. Ano, na druhou stranu je to samozřejmě i příčinou vyšší složitosti řešení relativně jednoduchých úkonů, neboť většina zodpovědnosti je přesunuta na programátora. Krásným příkladem je následující kód v Perlu a v C, který dělá dočista totéž, přečte jednu řádku z klávesnice a vypíše její obsah na obrazovku.
V Perlu:
$s = <STDIN>;
print("$s");
a v céčku:
char *s;
s = malloc(10);
if (fgets(s, 10, stdin) != NULL)
printf("%s", s);
free(s);
I kdybych nakrásně ponechal alokaci a uvolnění paměti pro řetězec „s“ na kompilátoru mírně odlišným zápisem kódu, je na první pohled vidět, že zatímco v Perlu se programátor nemusí starat o délku řetězce, v céčku je omezen tím, jak velký blok paměti je pro proměnnou přidělen (v našem případě 10 znaků včetně ukončovacího znaku 0).
Když si programátor s uvedeným kódem pohraje, dokáže samozřejmě zajistit, že se bude proměnná „s“ dynamicky „natahovat“ a třeba i zmenšovat podle potřeby. Bude to rychlé, bude to úsporné, ale bude to také potenciálně nebezpečné. Dojde-li při operacích s paměti k chybě, může být program jednak jádrem ukončen a jednak lze některé takové chyby (například v síťových službách) zneužít až k získání přístupu do systému, pokud víte, jak na to.
Obvyklé problémy jsou tři: přetečení/podtečení (češtináři prominou) bufferu (potenciální bezpečnostní díra), zápis/čtení mimo oblast paměti příslušící procesu (vedoucí obvykle k pádu programu) a neuvolnění přidělené paměti (způsobující zejména u dlouhodobě běžících démonu „nafukování“ programu a zbytečné plýtvání pamětí). Všechny tři chyby je bezpodmínečně nutné řešit. Jenže jak na to?
Relativně nejjednodušší je hledání chyb, kdy proces zapisuje nebo čte zcela mimo jeho vyhrazenou paměť. To způsobí vždy pád programu, neboť takovou operaci jádro vůbec nepřipustí. Při násilném ukončení procesu je na disk uložen do souboru core obsah paměti, kterou měl proces alokovanou. Pokud byl program zkompilován s ladícími informacemi, lze pak pomocí standardního debuggeru (např. gdb) snadno zjistit, na kterém řádku kódu program zhavaroval.
Někdy se ale stane, že program zkolabuje a gdb pak tvrdí, že spadl na nějaké zcela bezpečné operaci (například něco jako i = a * 2). V tomto případě si můžete být na 99% jist, že váš program někde za svého běhu přepsal paměť, kterou neměl. To může způsobit například změnu návratové adresy, takže program při opouštění podprogramu skočí úplně jinam, než by měl. Důsledkem je téměř vždy nelogické chování programu, ale občas se dokonce stane, že vše zdánlivě funguje dobře a chyba se projeví třeba až na jiném počítači. Pro odhalování podobných chyb jsou určeny speciální knihovny, kterým se někdy říká buffer overrun debugger. Takovou knihovnu přilinkujete k vašemu programu a tím máte zajištěno, že program spadne přesně ve chvíli, kdy k přetečení bufferu dojde. Pak již následuje výše zmíněné zkoumání core souboru vedoucí již tentokrát k odhalení skutečné chyby.
Asi nejznámější je knihovna Electric Fence, která je používána i v mnoha komerčních společnostech. Osobně s ní mám jenom ty nejlepší zkušenosti a vřele doporučuji vždy ozkoušet vaše programy s touto knihovnou, neboť jde o záležitost velice ošidnou a tento postup vám jistě ušetří mnohé starosti s rozzuřenými uživateli, kterým váš program nebude fungovat :)
Existují však i knihovny, které umí mnohem víc, než jenom detekovat přetečení bufferu. Jednou z nich je dmalloc. Tento „memory debugger“ jsem objevil teprve nedávno a vlastně jsem původně chtěl psát jenom o něm, ale nakonec jsem si řekl, že to vezmu obecněji.
Dmalloc dokáže hlavně výborně detekovat třetí zmiňovanou chybu, kterou je neuvolňování přidělené paměti. Program s přilinkovanou knihovnou dmalloc zapíše těsně před ukončením běhu programu do logu informace o neuvolněných blocích paměti. Pokud do zdrojového kódu vložíte pomocí řádku #include <dmalloc.h> hlavičkový soubor náležící ke knihovně, získáte z logu dokonce i přesnou informaci o tom, na kterém řádku zdrojáku došlo k alokaci paměti, jež nebyla uvolněna. Bez rekompilace programu (pomocí proměnné prostředí) můžete nastavovat parametry, kterými se řídí chování dmallocu, jako je například míra logování událostí. Lze nastavit množství různých testů, mezi nimi i ten na přetečení bufferu, ale přeci jenom je v tomhle o něco lepší Electric Fence. Výhodou je podpora multithreadových aplikací a částečně i C++.
Použití dmallocu mělo u mě v několika případech ještě jeden blahodárný vliv (i když možná nechtěný nebo náhodný). Když jsem totiž použil některé funkce pro práci s řetězci s omezenou délkou (například strncpy nebo strncat, nedoplnila se na konec cílového řetězce ukončovací nula (což je běžné chování těchto funkcí). Bez dmallocu program vypadal, že funguje, ale s ním dělal v těchto fázích doslova psí kusy. Zkoumáním jsem pak chybu odhalil a potřebný znak doplnil ručně. Jsem si jist, že ať už na mém či některém jiném počítači by se tato chyba dříve či později projevila i za běžného provozu.
Pokud tedy programujete v céčku a nechcete se i přes občasné těžkosti vzdát jeho možností (a také třeba rychlosti výsledných programů), měli byste rozhodně při své práci používat některé pomůcky pro ladění operací s pamětí. Já osobně nedám na kombinaci dmalloc a Electric Fence dopustit.
P.S. Kombinací myslím samozřejmě použití obou produktů, ale zvlášť. Kombinování více ladících nástrojů tohoto typu v jednom programu způsobí jedině problémy.
