Chyba vznikne snadno

3.5.2006 22:10 | Přečteno: 1601× | Gammu

Jak si tak čtu zprávičku o chybě v xkách a koukám na patch, který ji opravuje, tak se nemůžu ubránit pocitu, že tu samou chybu jsem dnes už někde viděl.

Po chvíli uvažování mi to docvakne a vzpomenu si na dnešní commit do python-gammu. Teď mi nezvbývá než souhlasit s těmi co tvrdí, že toto vznikne hrozně snadno .

       

Komentáře

[Jan Grmela]

Tyhle chyby jsou nejhorší.

Uvedu příklad: člověk něco nakóduje, pak mu to nefunguje dle očekávání, tak kus kódu zakomentuje, nechá jen "basic" část, která funguje. Postupně odkomentovává a zjišťuje, že nemá potuchy, kde by chyba mohla být. Nervozita. Smaže půlku kódu a napíše jej znovu. Pořád nic, chyba je jinde. Třískání klávesnicí o stůl. No a nakonec zjistí, že nový kód je mnohem hůř napsaný než ten starý a že prapůvodcem byl zapomenutý středník na 3. řádku.

Nevyhýbám se trvzení, že by to mohl být autobiografický příklad

[prOm3TheuS]

Jo, tohle jsem už někde viděl. Mám rád když lítaj písmenka z klávesnice

[Heron]

Hmm, ten patche vypadá hodně usměvně. Bohužel, něčemu podobnému se v C asi zabránit nedá, co?

geteuid je pointer na funkci, zatímco geteuid() je volání funkce, což je céčku jedno. Nebo existuje nějaký parser, který by na podobné konstrukce upozornil?

[Kníže Ignor]

Můžeš si vytvořit vlastní logické operace, které budou pracovat jen nad typem boolean, a relační operátory, které budou vracet jen typ boolean.

[Jan Kundrát (jkt)]

Cisty C umi operator overloading?

[Kníže Ignor]

Těžko. Ale to nepotřebuješ, bylo by to jen matoucí a dalším zdrojem chyb. Lepší se mi zdá vytvořit si novou sadu vlastních operátorů a ty používat (místo >, třeba .GT. ).

[Jan Kundrát (jkt)]

a definovat je pres #define ..., vid...

[Kníže Ignor]

Tak s tím .GT. to byl vtip, protože to je z Fortranu. Ale proč nepoužít funkce?

[Sinuhet]

Vylepsene C

[Sinuhet]

Jezisi takovyhle veci nepiste na verejnosti. Jeste se toho nekdo chytne a vazne to tak udela.

[Sinuhet]

Pretezovat operatory pro vestavene typy nejde ani v c++.

[Heron]

No nemyslel jsem upravou kódu, prostě jen nějaký prográmek, který by se mrknul na kód a určit by podle pravidel místa, která by mohla být nebezpečná.

Běžně kompilátory upozorňují na neinicializovanou proměnnou, tak proč ne na nevhodně použitý pointer? Tuším ale, že nějaký kompilátor mě za podobné "chyby" seřval (třeba i za = použité v if). Možná to byl ten k MSVSC++.

[Michal Čihař]

Za = v if seřve i gcc. Pointer se používá dost často, takže to asi warning není.

[Michal Kubeček]

Bohužel proti porovnání pointeru s nulou neprotestuje ani GCC4 s -Wall, dokonce mám neblahé tušení, že snad i přímo norma specifikuje, že to musí být přípustné (ale ruku do ohně bych za to nedal, musel bych se podívat). Je to celkem logické, idiomy typu 'if (!p)' se používají skoro všude. Navíc se i NULL často #definuje jako '0' místo '((void*) 0)'.

[Luk]

Mám dokonce dojem, že tam je něco jako:

#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void*) 0)
#elif

[zde]

Jenže v tomto případě to není pointer, ale compile-time konstanta, použitelná např. pro statickou definici, a gcc to samozřejmě ví.

[zde]

Tak zrovna tenhle warning se mi moc nelíbí a je myslím dosti pomýlený. Množství lidí kteří píšou v C a místo dvou rovnítek omylem napíšou jen jedno, a zároveň mají náhodou na levé straně lvalue se limitně blíží nule. A přidání závorek a explicitního srovnání s NULL čitelnost kódu jednoznačně *ZHORŠÍ*, protože na levé straně se pak nakupí minimálně dvě otevírací závorky vedle sebe. Viz idiomy:

while (curr = next_foo(bar))
  baz(curr);

while ((curr = next_foo(bar)) != NULL)
  baz(curr);

Stejně nechápu proč vlastně C trvá na závorkách kolem expr v příkazech if, while, for, switch, protože jsou obvykle redundantní a pouze snižují čitelnost. Zlatej python.

[Miloslav Ponkrác]

Zase ten zlatej Python neumí přiřazování v podmínkovém výrazu uvnitř if, while, apod.. takže jsem došel na to, že v Pythonu se leccos zapíše dost složitěji, než v C. Stejně tak jsem v Pythonu nenašel ani obdobu do while, ani skutečný cyklus for (to co jsem našel v Pythonu pod názvem for byl ve skutečnosti cyklus typu foreach). Ono je to vlastně jedno, jestli máte závorky kolem expr u if, while atd., nebo jestli tam máte dvojtečku na konci jako v Pythonu, nějaké ohraničení expr prostě potřebujete.

[Michal Vyskočil]

Python nebyl desingován jako mlátička, ale jako (více méně úspěně) elegantní nástroj, kdežto C je v podstatě makroassembler . Čímž nechci C shazovat, protože je to můj oblíbený jazyk, jenom je určen na něco trochu jiného.

[Michal Kubeček]

To bude tím, že hlavní důvodem vzniku C bylo to, aby v něm jeho autoři napsali operační systém. Takže se při jeho návrhu řídili výhradně praktickými hledisky. Hezky to ilustruje důvod, který uvádějí pro volbu = pro přiřazení a == pro porovnání: v programech se statisticky výrazně častěji přiřazuje než porovnává na rovnost, proto je pro přiřazení zvolen kratší operátor; na rozdíl od Pascalu, který byl stvořen jako jazyk pro výuku, jehož návrh zohledňuje spíše teoretická hlediska než praktická. Jinak by totiž Wirtha nikdy nemohlo napadnout něco tak šíleného, jako dát operátorům and a or vyšší prioritu než porovnávání (a takových příkladů by se v Pascalu našlo víc).

[Michal Vyskočil]

Však já nic jiného netvrdím . Jinak to srovnání bylo C vs Python, Pascal bych sem opravdu netahal.

[Luk]

Ano, microsoftí takové věci hlásí (ale zrovna to = jen jako warning). Ale zase nehlásí jiné, které hlásí GCC. To si nevybereš

Ale lze používat pomocné programy (jako např. splint), které leccos najdou.

[zde]

Pomocné programy jsou ze systémového hlediska dosti blbost, protože z velké části zbytečně duplikují celý preprocesor a parser z gcc. Mnohem lepší by byl pluginový systém pro gcc, kde by sis mohl naháčkovat kontroly na té úrovni překladu, kterou uznáš za vhodné, a pak jednoduše balíček rekompiloval.

[Luk]

To je sice pravda, ale v tuto chvíli je jediné řešení používat tyto nástroje (nebo nepoužívat a mít tam podobné chyby ).

[Michal Marek (twofish)]

Zrovna takový prográmejk přišel na tu chybu v Xorg.

[zde]

Především se mi zdá že test na "real uid je root nebo effective uid není root" jaksi postrádá smysl, jde o sčítání (logické or) hrušek s jablky. Jestli ten kód má nějaký smysl, rád bych se ho dozvěděl.

   /* First the options that are only allowed for root */
   if (getuid() == 0 || geteuid() != 0)

Jo a chybějící function call by mělo gcc v tomto případě hlásit, protože geteuid bez závorek je reference na externí symbol, tudíž je blbost jej castovat na bool.

[Michal Čihař]

Logika je asi taková, že pokud si root (getuid) tak to můžeš udělat. Pokud binárka je setuid a tím se nastaví efektivní uid na roota, tak ne. Pokud je binárka uživatelova a/nebo nemá setuid, tak si s tím může dělat cokoliv.

[zde]

Aha, už rozumím. Jenže X je a vždy bylo setuid root (jinak by ten šmejd nemohl na železo), takže geteuid() != 0 je vždy false, takže ten test tam IMHO nemá co dělat. A kdyby tam nebyl, nebyla by ani chyba :)

[Michal Kubeček]

X nemusí mít suid bit, pokud ho nepotřebujete spouštět interaktivně pomocí startx. Což dnes naprostá většina uživatelů nepotřebuje.

[zde]

Jenže pokud X není setuid, tak jej musí spouštět root, tudíž se druhý test s geteuid() v podmínce stejně přeskakuje a nemá tam tedy co dělat.

[xxxxxxxx]

kuli jednej zavorce sem dnes stahoval 88 MB rpmka v updatu

[Michal Čihař]

Máš používat distribuci která má Xka rozdělená .

[Jan Grmela]

Buď rád, že nemáš Gentoo jako já

[zde]

88Meg kvůll chybě v (pravděpodobně) nadbytečném kódu.. jaká ironie. :)