Pierwszym ''poważnym'' językiem programowania, którego się nauczyłem, był Pascal. Konkretnie, był to kompilator Turbo Pascal, wersja 4.0. Jedną z nielicznych opcji udostępnianych przez ów kompilator było wyłączenie kontroli przepełnienia stosu. Domyślnie, ma się rozumieć, kontrola stosu była włączona, o czym moje programy pascalowe informowały za pomocą komunikatu stack overflow, w szczególności przy wywołaniu nieskończonej rekurencji - co młodym adeptom informatyki zdarza się stosunkowo często.

Kolejnym językiem programowania, który poznałem, było C, i tutaj kontroli przepełnienia stosu nie dało się wyłączyć. Co gorsza, nie dało się jej także włączyć, podobnie jak kontroli zakresów, buforów, wskaźników, inicjalizacji obszarów pamięci i wielu, wielu innych rzeczy. Mówiąc dokładniej, kontrole te trzeba sobie samemu zaimplementować, na co oczywiście nigdy nikt nie ma czasu ani ochoty. Generalnie, kompilator C miał się do kompilatora Pascal jak brzytwa do nożyczek dla małych dzieci (takich niezbyt ostrych i z zaokrąglonymi czubkami, czytający to tatusiowie i mamusie maluchów na pewno wiedzą, o jakim modelu mówię). Długo wydawało mi się to wadą tego języka programowania, ale w porę uświadomili mnie koledzy z roku oraz panowie Kernighan i Ritchie, wtłaczając mi do głowy przekonanie, że brzytwa to najlepsze narzędzie do wszystkiego, nawet do wycinania gwiazdek z papieru. W przekonaniu tym, wstyd się przyznać, żyłem przez następnych kilka lat, tworząc programy w C pozbawione wszelkich kontroli stosu, zakresu, rozmiaru buforów itd. Nie robiłem tego w moich aplikacjach, sądząc, że na tym właśnie polega prawdziwie zaawansowane programowanie i ktoś, kto sprawdza np. długość tekstu przed wykonaniem strcpy do bufora, jest przewrażliwionym mięczakiem.

Piszę to wszystko, bo wielu, nazbyt wielu ludzi myślało podobnie jak ja. Bodaj najczęściej stosowanym przez hakerów wytrychem, pozwalającym wejść na dowolny system, jest właśnie przepełnienie stosu albo bufora. Gdyby programiści nie uważali kontroli zakresu, przepełnienia stosu czy długości zmiennej za coś niestosownego, niegodnego Prawdziwych Informatyków; gdyby kompilatory wykonywały to automatycznie; gdyby w pogoni za wątpliwą "optymalizacją" nie wyrugowano nawyku kontroli z programowania.... gdyby, gdyby, gdyby. Piszę to wszystko z dużym poczuciem winy, bo być może jakiś mój program jest teraz online i przez brak kontroli szerokości bufora lub przepełnienia stosu można się włamać na serwer, na którym jest posadowiony.

Pozwolę sobie przypomnieć, bo wszyscy jakoś zdążyli zapomnieć, że równie nieistotna i drobna decyzja programistyczna - zapisanie roku na dwóch cyfrach - miała ogromne konsekwencje. Naprawa jej skutków kosztowała grube miliony w skali całego globu. Podobnie miliony kosztuje zabezpieczanie serwerów przed błędami w rodzaju wyżej wymienionych; kolejne miliony zostaną wydane w najbliższych latach na ochronę przed spamem, którego to problemu można było uniknąć, gdyby odpowiednio pomyślano o mechanizmach bezpieczeństwa w SMTP.

Nie na darmo mówi się, że programowanie to - obok alkoholu oraz broni palnej - najszybszy na świecie sposób popełniania błędów. Ile takich prostych decyzji programistycznych będzie jeszcze kosztować miliony? To wie jeden Pan Bóg. Mogę natomiast być pewny, że wyciągnie nam On to wszystko, kiedy staniemy przed Jego obliczem. I jeżeli istnieje piekło informatyków, to w piekle tym będziemy się za to wszyscy smażyć na stosie - i zaręczam, że będzie to stos bardzo przepełniony.