Firefox prý obsahuje nejméně 726 problémů

IMO #t

na druhej strane slusny kod by nemal mat 'neslusne miesta', ktore by mohli byt povazovane za mozne problemy.

IMHO ziadny automaticky nastroj nedokaze rozlisit "skutocny problem" od "potencialneho problemu". Mam s par testovatkami skusenosti (napr. valgrind, java findbugs, nejaky C-ckove udelatko...)

Napr. pri pythone valgrind sype "invalid read" (pokial sa nezadefinuje urcity preprocessor symbol) takmer v kuse, pretoze python ma vlastny alokator pamate, alokuje pamat na "areny", co su 4-kB kusy pamate zarovnane na hranicu 4kB. Ak by nejaka architektura mala stranky mensie nez 4kB, tak by namiesto testu, ci je dana alokovana pamat uz "claimnuta ako arena", by sposobil segfault (nepamatam si to uz uplne presne, ale cca pred rokom som riesil ten problem, nakoniec sa ukazali memory leaky v nasej app).

Podobne, jedno C-ckove udelatko sa "chytalo" na strcpy, pricom strncpy ohodnotilo ako OK.
Lenze:
-pred strcpy sa da samozrejme porovnat a otestovat maximum
-pri strncpy sa to da zase naopak pos..t (ak sa clovek dost snazi ;-))

Napr. dost pochybujem, ze by nejake udelatko dokazalo vo FF detekovat, ze dakde mu chyba wait(), co je uz nakoniec mozno opravene, ale pamatam si, ze obcas nejake child procesy ostavali visiet.

K pythonu: bola tam funkcia int is_arena(void * addr) alebo podobneho nazvu/signatury. Otestovala ci na adrese addr&0xfffff000 je "signatura" pythonovskeho alokatora. Tj. ak dostala nejaky kus pamate alokovany obycajnym mallocom, sahala casto do neinicializovanej (pripadne nealokovanej) pamate. Ze to nesegfaultlo rovno je dane tym, ze (snad vsetky zname) architektury pouzivaju aspon 4kB stranky, inak by pagefault handler zistil, ze sa deje nejaky bordel. V podobnom zmysle je mozne najst v zdrojakoch pythonu komentar. Pre tu srandu, pregrepujte si zdrojaky pythonu na vyraz 'valgrind' :-)

To je ovšem docela divné --- co kdyby tam ta signatura byla náhodou? Nebo to pak platnost stránky ověřovalo ještě jinak?

A čo keď je to tak ze Klockwork K7 obsahuje 726 problémov ;)

Programy na staticku analyzu kodu mozu mat priblizne 50% ucinnost. To znamena, ze polovica hlaseni je skutocna chyba. Ale ...
ked uz raz kod prehnali takymto analyzerom, mohli opravit tu polovicu hlaseni a tych 726 je uz len falosnych hlaseni.

Používám FF 1.5.0.6 na WinXP a jsem přesvědčený že FF má problémy při práci s pamětí. Při otevření více tabů s různými stránkami se alokovaná paměť pohybuje klidně okolo 80 - 100 MB. Po zavírání jednotlivých tabů se alokovaný objem paměti nesnižuje, jak by se dalo čeka, ale zůstává víceméně stejný. Takže když skončím na závěr s jediným tabem, ve kterém je primitivní, převážně textová, stránka (např. starý www.linux.cz) a FF má alokováno celkem 80-100 MB paměti, říkám si že je tam něco shnilého.
Má někdo z vás podobnou zkušenost?

FF si nechava v pamati vsetky posledne otvorene stranky (aby ich v pripade potreby mohol rychlo zobrazit) takze aj ked sa zatvoria vstky taby, tak v pameti stale ostavaju. Existuje daky plug-in co to dokaze tuto cache vymazat a danu pamet uvolnit.

To by lecos vysvětlovalo - nevíš jak se ten plugin jmenuje?

Ze strany Klockworku jde samozřejmě o dobrý pokus o zviditelnění jejich produktu. A to bez ohledu na to, jestli těch 726 problémů je skutečných, potenciálních a nebo virtuálních. V každém případě se spousta lidí dozví, že existuje společnost Klockwork, která se zabývá statickou analýzou kódu. A o to, myslím, šlo.