Igen lehet és van is.
Tehát a felelős kód írogatás nem elhagyható követelmény. Ebbe körbe tartozik a tömbindex nem nyakrafaszra inkrementálgatása is.
Konkretizálva a framework/runtime/lib stb.-ben fellelhető hibákat:
Konkrétan memóriamenedzsert kellett írjunk anno, mert a Windowson akkoriban az okos malloc képtelen volt néhányezer pointert eladminisztrálni.
Pedig qrvára le akartam tojni ezt, akartam volna használni rendszer által biztosított erőforrás foglalási rutint.
Másik dolog pl. JAVA JVM.
Egyébként egy qrvajól megírt valami. Viszont adott garbage collector gennyesen ritkán előforduló hiba miatt folyamatosan szivatott bennünket.
Mire kiderítettük, hogy az egyébként jajdebiztos JVM garbage collector baszakszik, eltelt pár hónap.
Ennyit arról, hogy mennyire támaszkodjon az ember maximálisan Library-ker, framework-ökre.
Mindemellett ezzel nem azt mondtam, hogy mindent assemby-ben vagy direkt gépi kódban kellene megírni.
De azt viszont állítom, hogy a felelős programozási gyakorlatot nem helyettesítik a legjobban megírt fejelsztői eszközök vagy framework-ök sem.
Nálam a felelősség körébe tartozik a tömbindex normális kezelése is. Másnál meg nem.
Az, hogy a C-ben megírt OS közeli kódokban egy ilyen buffer overflow mekkora problémát tud okozni, anem a C nyelv problémája, hanem első szinten az OS-é, második szinten meg a programozóé.
JAVA-ban pl az, hogy egy adott hiba nyomán telefossa a logot Exceptionnel, az egyrészt normál működés, másrészt meg semmit sem old meg.
Az algoritmus ugyanúgy szar, ha egy akármilyen hivatkozás azért száll el mert Nul-ra akar az ember metódust hívni, vagy azért, mert olyan helyre akar 1 byte-ot odaírni, ahova nem szabadna.
A "nem szabadna" dolgot a programozónak kell tudni kezelni.
-----------------------------------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years - but Yoichi is coming up :)