Vlákno názorů k článku
Chyba v glibc umožňuje lokálně získat práva roota od cc - `exit(42)`? A potom někde jinde check na 42?...

`exit(42)`? A potom někde jinde check na 42? Tak nevím jestli ten opravený kód je o moc hezčí než ten chybný... Toto je podle mě hodně prasácký přístup u tak důležitého projektu...

Mě daleko víc děsí, udivuje a mrzí, že je tam to zpracování děláno úplně od nuly, tj. iterace po bajtech, pointer aritmetika, porovnávání s pár ASCII konstantami, atd.

Vždyť tohle je přece dávno vyřešený problém. Proč to pořád někdo zkouší vynalézt znova, pořád s těmi stejnými chybami?

A co malo by si to nacitat nejaku inu libc? Asi je to preto ze toto su inicializacne parametre (bootstrap) takze sa tam uvazuje o override vselicoho takze to musi byt urobene vsetko 'rucne'.

Nejprve si ten soubor přečtěte. Parsování proměnných se tam dělá od základu ručně, přitom i _v jiných částech glibc_ je tento identický problém řešen. Není to ani copy & paste, je to stejná myšlenka (env var obsahující A=B) napsaná trochu jinak, s novými chybami.

No p. Stech, glibc caka na vas patch "zjednotenie parsovania".

To je v testu, ne v kódu samotném.

A jaký je v tom rozdíl?

Podle mě když už potřebuju nějaké číslo použít více než 1x, tak z něho udělám konstantu, a tady opravdu nezáleží na programovacím jazyku. Schválení takového kódu je podle mě u jakéhokoliv projektu špatný precedent.

A argument, že testy se prasit můžou neberu, ono i ty testy někdo bude v budoucnu číst, když mu třeba selžou...

S těma testama bacha. Je rozdíl, jestli chci testovat že program vrací 42, nebo vrací nějaký ANSWER_CODE z header.h.

Pokud chci tu první možnost, tak není dobrý nápad v testu použít to makro. Protože pak ten test neodhalí, že do toho headeru někdo zasáhl a tu konstantu změnil.

Toto je kvalitni prispevek. Neni nic horsiho pro kvalitu kodu nez developer ktery i pise testy na vlastni sw a v ramci deduplikace casti kodu nemysli na vyssi koncepty testovatelnosti.