>
> Zgodze sie, ze na tle innych powszechnie uzywanych jezykow
>
> C jest wyjatkowo wymagajacy pod wzgledem wiedzy, jaka musi
>
> posiasc programista, zeby moc w nim bezpiecznie programowac,
>
> i ma to do siebie, ze potrafi zaskakiwac (z powodu takich
>
> cech, jak np. koniecznosc recznej alokacji pamieci czy
>
> sprawdzania zakresow, czy obecnosc funkcji bibliotecznych,
>
> ktore same moga przepelniac bufory).
>
>
casty, pointery, niesprawdzanie zakresów, czy
moze nawet malloc/free jako zrodło błedów są
chyba jednynie popularna blablaniną (nie jestem
moze zupelnie pewien ale ja pisze w c i nie mialem chyba NIGDY błedu zwiazanego z
castem i mw tyle
samo w zwiazku z pozostalymi kwestiami tj problem wogole nie istnieje, czy tez nie
istnial,
dokladniej to jak sie uruchamia kod na wskaznikah
to w etapie rozruchowym mozna miec pare bledów runtime (co mi sie akurat zdarzylo ale
po etepie
rozruchowym juz raczej nie - dokladnie nawet nie wiem bo niezwykle jednak rzdko pisze
kody na wskaznikach) generalne ijednak z mojego osobistego
doswiadczenia wynika ze to cale blablanie o niebezpieczeństwach c jest nie warte
czasu
na jego czytanie

malloc i free tez nie uzywam tak ze nie wiem,
gdybym uzywal to pewnie bym sobue napisał wrapper
ktory by mi sprawdzał czy tylezaalokowano co zdealokowano

natomiast bledy w bibliotekach to owszem sa
to pewnie powazne błedy (na przykład to jesli biblioteka jak ktos na pl.c.l.c
okreslil produkuje pamiec itp, albo scanf które mozna wywalic inputem itp

sczerze mowiac dla mnie przy pisaniu bledy wogole nie sa problemem nie na tyle by
warto bylo o nich
wspominac (czasem sie trafi cos na czym zmarnuje ze
dwie godziny ale w sumie rzadko)

gorsza kategoria jest np taki przypadek ze cos nie chce działać (na przyklad ostatnio
opencl - ale to
scisle nie jest kategoria błedów tylko problem przebijania sie przez dokumentacje i
konfiguracje czy cos takiego ;\ :C