David A. Wheeler - Apple gotofail

Titkosítás, biztonság, privát szféra

David A. Wheeler a shellshock összefoglalójához hasonlóan egy részletes összefoglalót készített az Apple "gotofail" néven elhíresült, széles körben nyilvánossá vált sebezhetőségéről. Aki csak felületesen tájékozódott eddig a problémáról, annak most egy helyre összeszedte a szerző a legfontosabb részleteket, tudnivalókat. Elolvasható itt.

( joco01 v | 2014. 11. 27., cs – 09:35 )

Vajon mikor lesz divat unit tesztet írni legalább a kritikus kódrészekre...

--

A goto failt pont megfogta volna egy unit teszt, mert nem crash jellegű (buffer overflow és társai), hanem logikai hiba volt (tök szabályos alap inputokra rossz eredményt adott vissza). Ezen felül van értelme az invalid inputokra történő nem definiált működést ellenőrizni. Vagy meg kell írni C#/Java-ban, ahol olyan kb. nincs :).

--

( fajan | 2014. 11. 27., cs – 22:46 )

hahh, a legtöbb code-styling érve: "avoid brackets to save vertical space"...
a 16:9 visszacsap: használj 9:16-ot :D (egy monitoron a 5:4 esetleg 4:3 az rendben, de komolyabb munkára a 16:10/FHD-t is érdemes forgatni... nincs 3/4k tapasztalat)

Ez baromsag amugy. Nalam most egy 16:9-es kijelzo van, egyszerre 70 sor kodot latok. Ha egy kodblokk (metodus etc.) ennel hosszabb, ott mar eleve baj van es szet kell tordelni ep esszel felfoghato reszekre.
Ebben a 70 sorban amugy 4 metodus is van, kommentezve. Szoval nem a "wasting vertical space" a bad practice, hanem az, hogy kilometer hosszu kodblokkokat akarnak egyesek atlatni. Plusz van code folding, akinek az a problemaja, hogy nem latja a hivasok parameterezeset (a belso mukodest amugy sem szabadna latni, csak az allapotvaltozast. Az meg benne van a nevben vagy dokumentacioban).

+1

Ha minden fejlesztő betartaná legalább ezt a szabályt, ritkán látnál 10-20 sornál hosszabb metódusokat. Persze ezt könnyebb egy oop nyelvben megvalósítani, mert a sok segédfüggvény (metódus) nem szennyezi a névteret, mivel mind privát lesz.

A másik dolog, hogy egy widescreen monitoron nem muszáj csak a kódot megjeleníteni, oldalt megjeleníthetsz más információkat (pl. a fájlban levő függvények listáját), ami inkább gyorsítja és kényelmesebbé teszi a kódolást, mint lassítja.

> Ez baromsag amugy.
Köszönöm, tiéd is.

> Ha egy kodblokk (metodus etc.) ennel hosszabb, ott mar eleve baj van es szet kell tordelni ep esszel felfoghato reszekre.
Attól függ miről van szó. Egy statikus nyelvnél, persze hogy jó a sok függvény + tudsz makrózni meg inline-olni, mert ezt tökéletesen megoldja az "-O2". Még talán az okosabb és jobban optimalizáltabb JIT-eknek se jelent "túl nagy" overhead-et. Ellen pl. PHP (és más hasonló dynamic/interpreted, ahol a linkek azok runtime-resolved-ek) esetében a függvényhívás általában eléggé költséges és emiatt kerülendő (pláne oop overriden/overloaded methods vagy többszörös nesting esetén).

> Plusz van code folding, akinek az a problemaja, hogy nem latja a hivasok parameterezeset [...]
Most az egyik projectem (raster->vector) esetén: már maga csak _egy_ if feltétel meg lehet 5-10 sor sok esetben, ha a kiértékelési sorrenddel is akarsz kicsit optimalizálni (PHP-nél gyakorlatilag muszáj, ha nem filmet akarsz nézni a test-run-ok közben): akkor ráadás 2-3 nesting (ami indent-elve ezerszer átláthatóbb). Ezt egy sorba is írhatod, csak akkor nem látod át. És ilyen feltételekből van legalább 5-8 még egy szimplább neighbourhood-analysis során is: 70 sor kevéske, és valszeg page-up/down kell (még foldingolva is), hogy egy teljest függvényt átláss (átlátogass), pláne ha nem a "szimplább" féle...