Vlákno názorů k článku
Úvahy o Borrow Checkeru pro C++
od RDa - Google v loňském roce zveřejnil dnes již velmi...
-
Google v loňském roce zveřejnil dnes již velmi známou statistiku, že cca. 70% bezpečnostních chyb v prohlížeči Chrome/Chromium je způsobeno špatnou správou paměti.
Tak to nevim zda bych se verejne chlubil tim, ze mam takto spatne programatory, jeste horsi vedeni projektu, a zcela chybejici QA procesy? :-)
Je tedy logické, že jeho vývojáři hledají způsob, jak tuto situaci zlepšit.
Vyhazet indy a vsechny kteri se na pozici dostali kvuli kvotam, a najmout skutecne programatory.
A ne, C ani C++ nemuze za to, ze nekdo neumi psat dobrej kod, pripadne ze nekdo nechava zakladni pametove alokace/dealokace na libovuli anarchisticke smecky tvorici jakysi produkt.
-
Tak to je mýtus a zrejme aj nafúkanosť/neznalosť poniektorých programátorov.
Prečítajte si štatistiku:
https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/Google, Apple, Ubuntu, Firefox reportujú, že veľká čast bezpečnostných chýb je
spôsobená jazykmi C a C++. Žiaľ, nič na tom nemení aj používanie smart pointerov v C++.Ak si tieto veľké firmy (údajne) nevedia nájsť schopných programátorov, tak potom kto to dokáže?
Ako, keď následkom pamäťových chýb spadne aplikácie, čert to ber. Ale tu ide o životy a majetok ľudí. Osobne by som si rozhodne nechcel brať toto na svoje svedomie. Preto pre kritické aplikácie je potrebné použiť technológie, ktoré tieto kritické chyby eliminujú.
-
No, v korporatoch okrem programatorov treba uzivit aj suitu okolo programatorov. Projektakov, analytikov, kamosov/kamosky, rodinu, potom to vyda na niekolko seniorov, viacero juniorov ktori sedia lokalne a mrte indov remote... seniori napokon nestihaju programovat, pretoze vysvetluju indom ze nie vsade na svete ma mena 6 desatinnych miest, mentoruju juniorov a ked vyda cas tak robia code review a merguju vetvy v gite... a tuto idylku im sem tam narusi particka produktakov po intenzivnom brainstormingu, to musia este seniori filtrovat relativne dobre myslienky od dusevnych zvratkov...
-
[Calculon]
Coz je na jednu stranu sice dobre, ale na druhou stranu si tak mozna delaji medvedi sluzbu. Kdyz hodi odpovednost z vyvojare na jazyk, neverim tomu ze potom budou mit lepsi produkty....A je taky otazka jak moc to funguje. Vem si ze za pomerne kratkou dobu tech jazyku docela pribylo. Z tech nejznamejsich jen Rust, Go, Vala....
Nevim, ja jsem v tomhle hodne skepticky.
26. 9. 2021, 22:49 editováno autorem komentáře
-
Nechci posuzovat, jestli to povede k lepším produktům nebo jak moc to funguje. Nicméně tak trochu jsem ve vleku událostí, protože mnoho projektů, ke kterým se dostanu, je teď buď v Go, nebo v Rustu. Nejlepší jsou ty, kde je kus starého C++, nad tím vrstva Go, do které se ono C++ postupně přepisuje, a zároveň už se z druhého konce portuje kód v Go do Rustu.
-
To se naopak porovnává dost snadno, Java prostě provádí bounds checking za běhu úplně stejně, jako třeba std::vector v C++.
K tomu názoru na Javisty: předem se omouvám těm, kterých se to netýká, protože je to samozřejmě klišé, nicméně souhlasím, že Javisti většinou nejsou dobří vývojáři. Ovšem ne proto, že nedělají správu paměti ručně, ale proto, že to jsou patlalové kódu, kteří nerozumí základům počítačové vědy a myslí si, že problémy se instinktivně řeší napsáním dalších řádků namísto důkazu teorému. To mají společné s céčkaři c++kaři, co takzvaně "vědí, co dělají" a žádnou statickou analýzu nepotřebují.
-
Nemusíš, v Pascalu, Adě, Rustu i v C++ (myslím tím vector) se pole přealokovávají transparentně tak, že se o to programátor nemusí starat. Samozřejmě že standardní knihovna musí mít rutinu na realokaci nebo ji kompilátor musí generovat, ale totéž platí pro interpretované jazyky, kde musí být součástí interpretu. Explicitně nebo implicitně je to v obou případech stejné.
-
No, a toto je presne to co vam ziadny prekladac neodhali, v buffri budu zvedsa binarne data ktore vo vecsine pripadov nebudu mat pevnu strukturu. Takze mate zhruba dve moznosti, bud pouzijete pointer alebo budete tie data z buffra prechadzat byte po byte. To suvisi aj so strukturou kodu, ak to chcete mat ten kod rozdeleny do funkcii tak aby z toho nevznikol spagetak tak budete musiet pouzit pointer na aktualnu poziciu v buffri. Ako vam staticka analyza odhali ze idete mimo buffer, ked staticka analyza pri preklade nemoze vediet, kde sa nachadza v buffri zaciatok struktury ktora funkcia spracovava, kedze tie binarne data nemoze mat k dispozicii. Toto moze osetrit len programator, ak na to mysli. A mysliet by na to mal, miesto toho ze sa bude spolihat na nejaku barlicku ktoru mu ponuka prekladac.
-
Filip JirsákStříbrný podporovateldw: Pro vaši informaci, pole v Javě jsou úplně stejná, jako v C – alokovaná paměť a ukazatel na ni.
A jak už psali ostatní, s interpretovaným nebo kompilovaným jazykem to vůbec nijak nesouvisí. Ostatně můžete mít i interpretované C, na druhou stranu Java se běžně za běhu kompiluje do nativního kódu a dnes už můžete Javu kompilovat do nativního kódu i předem. Takže vlastnosti jazyka nijak nezávisí na tom, zda je kompilovaný nebo interpretovaný – to totiž závisí jenom na tom, zda někdo napsal příslušný interpret nebo kompilátor.
-
nil nil (neregistrovaný)
@klokan
To mají společné s céčkaři c++kaři, co takzvaně "vědí, co dělají" a žádnou statickou analýzu nepotřebují.
Obdobu toho přístupu najdete všude ... a to nejen v programování. To je kombinace sklonu k lajdáctví a přebujelého ega - to je totiž to hlavní co výsledek takové analýzy zboří, řádky kódu se příší daleko snadněji ...
27. 9. 2021, 10:24 editováno autorem komentáře
-
Kvůli tomu vzniklo údajně i Go. Má GC, kontroluje indexy, dělá escape analýzu, aby dalo potřebné objekty na haldu atd. Ono totiž i špičkový vývojář s magistrem z astrofyziky a PhD z CERNu naseká v kódu bugy. Může perfektně zvládnout koncept a návrh, ukázkově celou architekturu, ale jakmile se začne psát kód, dochází prostě k chybám. Proto se používá silná typová kontrola, testy, statická analýza a podobné vymoženosti.
-
Len tie jayky maju jednu spolocnu chybu, ak pouzivaju nejake volania kniznic systemu, tak neovplyvnia ako sa chovaju kniznice ktore boli napisane v C. Ze by koli tomu vsetci opustili C a zacali pisat v ruste? Trocha strasidelna predstava, ze by mal jadro pisat niekto kto si mysli ze chyby za neho odchyta prekladac.
-
Smazaný profil
Ty už to raději zabal. Co slovo to lež. Hned na začátku se omlouvám že reaguji, ale občas mi to prostě nedá.
Podle mne mohu ovlivnit jak se knihovno chová poměrně snadno. Například tím, že ji použiji jak se má a jak bylo zamýšleno.
Pokud se knihovna podle toho nezachová tak je to její problém a ne můj a ani jazyka.
Co se tvých představ týče, tak to asi nechám na tobě, ale řeknu ti že se na jádru (nevím o jakém se přesně bavíš, já budu zmiňovat jádro linuxu) podílí poměrně velká skupina lidí. A pevně věřím že je mezi nimi i velká část lidí co věří, že je od chyb oddělí jazyk či překladač (případně jim pomůže se jim vyhnout).
A to mluvím i sám za sebe. Jelikož jsem měl tu čest se s pár vývojáři bavit a i sám poslat vlastní patch do jádra , který byl začleněn.
Jo a to mimochodem patřím mezi lidi co Rust a Go moc nemají v oblibě (pravda stále je miluji s porovnání s Javou). Ale i tak jim přeji úspěch a pokud se jim bude dařit tak je rád budu podporovat.
28. 9. 2021 9:30 upraveno moderátorem, důvod: Prosíme slušně! -
Tak jsou veci ktere jsou tezce viditelne, to jo - treba v pocatcich vyvoje na AVR me kolidoval stack s heapem (asi nejake mensi mcu), protoze to chtelo nastavit heap max v dobe kompilace a malloc zacal nejspis zhora.
Takze jsem si napsal analyzer, kteremu das AVR binarku, udela to disasm, projde vsechna volani a posuvy stacku kvuli lokalnim promennym.. a vypise to worst-case call path a velikost na stacku (promenne + navratove adresy, taky worst case interrupt). Volani pres pointer je nutno specifikovat vyctem co se muze volat - a rekurze chce vedet kolikrat asi se to vnori prinejhorsim (vetsinou to byva zname cislo).
Tohle me krasne pomaha najit magicke cislo, kolik pameti se ma rezervovat pro stack pro dany projekt, a kolik zbejva na dynamicke chovani. Buhvi zda neco takoveho existuje verejne, a last modify na tom svem toolu mam 8.5.2012 ... no dokonalost sama :)
-
Smazaný profil
To jsi napsal hezky. Ono PhD z CERNu je prostě ukázka člověka co vlastně nemusí vůbec umět programovat. Tím jen chci podotknout že to vůbec není o titulech a místech. Každopádně souhlasím s tím, že k chybám dochází všude. Na všech úrovních a jazycích.
Jasný že existují lidé co jsou opatrní, extra opatrní a ty bez chyby jako já. Ale né každý se tam může řadit.
To byl samozřejmě vtip. Dělám chyby denně a s věkem čím dál víc a jako mladý jsem je dělal možná ještě víc. Prostě chybovat je lidské.
Takže jakýkoliv nástroj co mi umožní své chyby odhalit a i ideálně napravit vždy vítám. A proto jsem si zvolil jazyk D. Umožnil mi psát dle mých představ. Zaručil mi poměrně velké bezpečí toho že nedělám chyby a zároveň vše fungovalo dobře a rychle. A zároveň dělá vše co jsi psal (GC - což je v podstatě jakákolv automatická správa paměti i RC a ARC, nebavím se o borrow checkingu), částečně má i podporu správy paměti jako má rust, dělá kontrolu že nezasahuji mimo buffer, že nepracuji s již nevalidní pamětí atd.
Takže za mne zatím jazyk který mi nabízí veškeré výhody a nemusím platit co jse pohledu výkonu týče (krom C++, ale tam mi ještě chybí pár drobností).
-
[klokan]
To je moc rychle generalizovane. Napr. Chyba v window manageru se neprojevovala, jen padem aplikace, ale napriklad spatnym navazovanim poradi oken na sebe. Tzn, ne vzdy doslo k cteni/zapisu do nealokovane pameti, a obavam se ze predikovat by to asi slo blbe - Stak oken byl implementovan jako zretezeny seznam. Jenze byl prasacky napsany.27. 9. 2021, 00:11 editováno autorem komentáře
-
No ale vždyť právě o to jde. Je spousta chyb, které se projevují sporadicky, jsou špatně reprodukovatelné, těžko se diagnostikují, ale statická analýza je dokáže odhalit a zařve už při kompilaci tak, že nic prasácky napsaného se přes ni nedostane. Pro uživatele to znamená mnohem bezpečnější a kvalitnější software, pro vývojáře je to obrovská úspora času.
-
[klokan]
"Je spousta chyb, které se projevují sporadicky, jsou špatně reprodukovatelné, těžko se diagnostikují, ale statická analýza je dokáže odhalit a zařve už při kompilaci tak, že nic prasácky napsaného se přes ni nedostane."
Pritom nejednodusi resenim muze v dane situaci byt, proste na to jit jinak. Jako kdyz nekdo misto toho aby rodelil komplexni problem na nekolik mensich, pruhlednych, dobre testovatelnych jednotek, napise heper-molochoidni tridu, ktera navic jeste hraje poker, vari kafe a ve volnem case pere zaclony (coz byl presne ten hlavni problem vyse zminovaneho prikladu), tak holt to podle toho taky dopadne.
Takze vsechno o cem tu pises je super, ale ze spatneho programatora to zazrakem dobreho neudela, a stejne tak to neudela ze spatneho navrhu, dobry program.
P.S. Jestli by Rust dokazal odhalit chybu - kterou jsem popisoval - uz pri kompilaci, musel by mit v sobe implementovanou vesteckou kouli.
27. 9. 2021, 22:15 editováno autorem komentáře
-
A jak by to jako v praxi fungovalo? Že si člověk v náhlém momentu jasnozřivosti uvědomí, že tam jsou chyby, které se ještě neprojevily, a půjde na to jinak? Nebo když najednou po vydání stabilní verze začne dostávat hlášky o pádech a chybách, které na první pohled vypadají každá úplně jinak? Není rozumnější mít statickou analýzu, která špatně napsaný kód prostě nepustí dál, a člověka přinutí na to jít jinak hned od začátku?
-
Proste prekladac ma robit to co mu programator povie, nie to co uzna za vhodne. Ak mu to povedat nevie a ocakava ze to prekladac urobi sam, tak len zbytocne zaberal miesto na skole niekomu kto by nepotreboval barlicky aby jeho kod bol bezpecny.
Co sa tyka chyb, tak casto su pisane zamerne v testoch a tie testy chceme prelozit.
A co sa tyka nepovsimnutych chyb v kode. Ak si tie chyby nevsimente vy, tak to este neznamena ze si ich nebude vsimat niekto iny.
-
"Vy jste zkrátka machr, Hlaváčku" :)
Tak například fly-by-wire systém u Airbusu je ve SCADE, což je formální modelovací jazyk, který se pak automaticky kompiluje do podmnožiny C. Pro nějaké tzv. "dobré programátory" tam naštěstí není místo a od té doby, co vinou "dobrého programátora" radioterapeutický přístroj TERAC 25 zabil několik lidí a několik dalších doživotně zmrzačil by tihle rádoby borci měli mít absolutní zákaz programovat byť jenom příkaz "echo".
Mimochodem Rust provádí mnohem hlubší statickou analýzu, než Ada (ta ale naopak má některé runtime kontroly, které Rust neumí). Právě to je jeden z důvodů, proč je tradiční Ada na ústupu a místo ní se teď často používá SPARK, který se ke statické analýze hodí líp.
Rust se tam nepoužívá z jednoho velmi jednoduchého důvodu: neexistuje pro něj certifikovaný překladač. Třeba se časem taky objeví, uvidíme.
-
SPARK je rozsirenie ADA. Ked pisem o kritickych systemoch, tak tym myslim napr. riadiacu jednotku prudoveho motora. Liedadlo vo vzduchu udrzite ak ma aj hydraulicke riadenie, nemusi mat nutne elektronicke. Kdezto prudovy motor je bez riadiacej jednotky v chode udrzat dost problem.
No, ja som k vedomiu ze c++ je nahovno, nejaky rust nepotreboval(ktory je tiez na hovno, len v inych odtienoch hnedej). Pouzivam jazyk podla toho ktory sa k ulohe viac hodi. Bud C, Adu(ak je nutne tak pocukrovanu sparkom), plpgsql (podmnozina ady), python, nim (tiez je kompilovany cez C), PHP (ako html preprocesor je skvele) a pozeram ked mam cas na eiffel, ten v praxi este nepouzivam...
Kdezto ako citam vas tak rust je usecase na vsetko. Nezavana to tak trocha diletanstvom?
-
SPARK je částěčně rozšířená ADA ale zároveň částečné omezená, takže spíš je to jiná množina, ale samozřejmě s obrovským průnikem. A u toho letadla je to jak u kterého, Airbus bez elektroniky ve vzduchu neudržíte ani v Direct Law (Boeing jak který...)
Nevím, kde jste sebral, že podle mne je Rust na všechno. Takovou blbost jsem určitě nikde nenapsal, mj. už proto, že sám používám různé jazyky a pro Rust vidím užší nasazení, než mnozí lidé (např. moc nechápu proč programovat WASM aplikace v Rustu, ale přesto to hodně lidí dělá. Třeba k tomu mají nějaký dobrý důvod který já nevidím, to je možné). To, o čem je řeč, je představa, že statická analýza je na hovno protože jsem přece "dobrý programátor". Osobně vidím diletanství právě v tom.
-
Syntakticka analyza ma zmysel pri jazykoch kde je algoritmus dostatocne detailne deklarovany. Ak ste uz videl nejaky rozsiahlejsi kod v ade tak viete o com hovorim. Ale ani tak nie je zazracny, jedna z utilit gnat toolesetu je specialne pre kontrolu skompilovaneho programu ohladne jeho prace s pamatou.
Co sa tyka dobreho programatora, toho tvoria jeho navyky a predispozicie. Jednoducho nerobi spagety (nezkrizi niekoko algoritmov do jedneho) a zavislosti cez x algoritmov. Ked pracuje s buffrom tak ma mat ten kod napisany tak aby na prvy pohlad videl ci je mozne aby zapisoval mimo alokovanu pamat. Ak alokuje pamat tak ju nema dealokovat na 20 miestach napriec celou aplikaciou.
On ten problem chromu podla mna nebude v C++ ale v ludoch ktori ho programuju a nemaju dobre navyky + ludoch co tych programatorov tlacia k tomu aby kod vydali co najrychlejsie na ukor toho aby bola urobena dobra analyza zadania a aby bol kod dostatocne otestovany. Zmena jazyka by tam neznamenala riesenie priciny ale riesenie dosledku.
-
Jistě jste chtěl říct statická analýza, ne "syntaktická analýza" kterou provádí i cmd.exe. Problém je samozřejmě v lidech, resp. v tom, že v projektu o desítkách MLoC na kterém pracuje mnoho různých týmů (ani ne jednotlivců, ale rovnou týmů - V8, Blink atd...) je lidsky absolutně vyloučené neudělat chybu. Kde se sakra odalokovává objekt xyz? Kdo k němu má přístup v který moment? Atd...
Takže představa, že se to vyřeší "lepšími návyky" a lepším testováním je prostě naivní. Ono totiž programovat takový projekt není totéž, co programovat hobby program o 20 KLoC jenom trochu větší, je to kvalitativně i koncepčně naprosto odlišný problém. Kdybyste měl pravdu, tak by na to u toho Googlu, Microsoftu apod. byli přišli taky a ty "lepší návyky" jim mohly ušetřit 70% zranitelností.
Co naopak může pomoct je automatizace těch "lepších návyků" tak, aby se chybný kód přes ni prostě nedostal, a samozřejmě nejefektivnější to je, když je to součást samotné definice jazyka. On ten Hoare v Mozille taky nebyl žádný idiot a dobře věděl, proč začal vyvíjet Rust.
-
[klokan]
Ale ja nic takoveho sakra nepisu! Ty porad nechapes ze slo o jeden z prikladu z praxe, kdy dusledkem blbeho pristupu programtora doslo k chybnemu fungovani procesu, jehoz jednim z dusledku bylo, ze za urcite vicemene nahodne kombinace udalosti dochazelo k chybnym vystupum a mohl vest dokonce i k padu cele aplikace. A takovou behovou chybu ti zadna staticka analyza proste neodhali. A diky prave tomu pristupu meho predchudce bylo nejschudnejsim resenim pak cely ten zatraceny stack prepsat.Jedine, co se snazim celou dobu rict je, ze bezpecne aplikace lze v psat i v C++. Nerikam nikde, ze existuji zazracne postupy jak se vyhnout chybam. Neexistuji a taky si uvedomuji, ze existuje vic druhu chyb, nez jen uniky pameti, nebo chybny pristup do pameti. Ale rikam, ze to, jak rychly a jak moc komplikovany bude cely proces jejich odhalovani, zalezi na pristupu k navrhu a implementaci, bez ohledu na pouzity jazyk. Kdyz pustis kompilator spatne navrzenou aplikaci a prasacky implementovany kod je uz davno pozde! To uz davno neni - jak pises 'od zacatku'...
28. 9. 2021, 10:47 editováno autorem komentáře
-
Určité situace s chybnými výstupy vlivem chyb v kódu statická analýza odhalí, na př. v tom Rustu (když už je o něm řeč) jsou vyloučené velmi běžné typy race condition. Ano, bezpečný kód lze psát i v C++, stejně jako ho lze psát i v assembleru. Problém je, že u netriviálních projektů z toho vyplývají exponenciální komplikace a náklady, nemluvně o tom, že čím větší projekt, tím větší jistota, že kód v C++ bezpečný prostě nebude. Proto je cíl nasazovat automatickou analýzu a jazyky, které ji mají přímo v definici. Cílem totiž zůstává mít kvalitnější software, ne svět přizpůsobit tak, aby se fanboyové C++ necítili dotčeni.
-
Je to i jazykem.
Kdyz jazyk neumozni pad, tak se pad neudeje. Nekdo psal, ze std::vector je bezpecny a s tim se da souhlasit.
Kdyby se pro pole prestali uzivat raw pointery, tak nemame zneuzitelny buffer overflow.Kdyby jazyk znemoznil jine sdileni dat mezi vlakny krome future/promise, tak by razem temer zmizli race conditions.
Pak je otazka, jestli to ma dostatecnou expresivni silu a bezi to dost rychle. Kdyz ne, tak treba zustat u starych problemu.
-
Cim viac obmedzeni, tym nizsia flexibilita. Naviac obmedzenia pri preklade ktore nemozu mat vplyv na uz prelozene linkovane kniznice je k nicomu.
Ale hadam sa potvrdi myslienkovy experiment pana Borela. Posadime ku klavesnice opicu ktora ked bude do klavesnice busit dostatocne dlhu dobu tak napise umelecke dielo a aby sme to urychlili tak tam dame filtre...
-
Kdyz hodi odpovednost z vyvojare na jazyk, neverim tomu ze potom budou mit lepsi produkty....
Never, ale cela odvetvi, kde opravdu o neco jde (o zivoty) se snazi maximalne eliminovat rizika selhani lidskeho faktoru, i kdyz se jedna o nadstandardne vyskoleny personal, protoze vi, ze se na nej neda 100% spolehnout a driv nebo pozdeji se dopusti chyby. Typicky priklad letectvi. Sice mas vyskolene piloty s pravidelnym prezkusovanim, ale i tak je cely system rizeni nastaveny, aby se pilot nedopustil chyby. A kdyz se pokusi udelat chybu, je durazne upozornovan, ze se blizi problem. Proc by to nemelo fungovat i v programovani?
-
Nikdy jsem moc nerozuměl tomu kultu kolem Plan9, co na něm má být tak úžasného. Podle mne to byl prostě experiment jakých jsou tisíce, a mnohé z nich se ukázaly přínosnější.
Dneska se Pike motá kolem komunity suckless vůči které mám absolutní averzi a neumím si představit, že bych kohokoli z nich považoval za rozumného vývojáře. Poslední věc, co jsem od Pika četl na blogu (už je to nějaká doba) je, že by se suckless měl dělat v Go. Takže asi tak.
-
Zdravim RDa, co jeste nikdy nezavlekl do programu bug.
C++ za to mozna nemuze, ale sprava pameti neni tezka u projektiku co vypisuje "Hello World". Je to tezke kdyz musis interagovat s cizimi knihovnami, ktere maji interni stav, kvuli rychlosti treba nemohou vsechno kopirovat, interfacy jsou dane, strojovy kod pristupujici k objektum v pameti se generuje za behu, neco musi byt thread safe atd.
Pak treba knihovne predas (v zmyslu std::move pro unique pointer) dva objekty ktere cez nekolik objektu pouzivaji neco spolecneho a za jistych okolnosti se musis zajimat, v jakem poradi se volaji destruktory. To cele kvuli kodu, o kterem nemas jak vedet, kdyz nectes vsechny implementace.
-
RDa hlavne nepouziva 3rd party knihovny (a takove cross-concept bastly jak jsi popsal netvori) a pise si svuj vlastni kod kteremu rozumi. Bugy se sem tam stanou, ale to odhali uz vetsinou uz moje integracni faze, kdy se kod zacne pouzivat nad ramec piskoviste kde vznikl.
Vyjimecne se stane, ze se bug, za ktery muze muj kod dostane mimo me, ale i ten posledni zachytilo dlouhodobejsi predprodukcni testovani u zakaznika - a to jsem za to mohl jen z pulky, protoze slo o sw vs. hw race condition. Byl to ale zajimavy proces, kdyz Ti zareportuji podivne chovani s urcitym patternem - a hned bylo zrejme, ze ktera cast kodu za to muze. Opraveno obratem.
Ale ja jsem divnej - ale nepouzivam ani debugger, ani verzovani. A jediny 350KLoC codebase v C sdili vsechny projekty urciteho druhu - takze to je opakovane "testovano" a pripadne vylepsovano - bez nutnosti podivnych branchu a merge konfliktu.
Nejvetsi for je totiz ten, ze kdyz se snazite neco poslepovat z 3rd party veci kvuli jednoduchosti, tak dojedete na tu integracni slozitost :-)
-
350 KLoC napříč všemi projekty je absolutní nic. Firefox má nějakých 20 MLoC a to zdaleka není nejvetší současný open source projekt. Takže při vší úctě evidentně nemáš zkušenost s prací na velkém projektu, do kterého je zapojená spousta lidí.
A 3rd party knihovny se používají z dobrého důvodu: napsat správě a hlavně bezpečně dejme tomu random generátor, krypto nebo třeba jpeg loader není tak úplně jednoduché a je lepší, když to někdo vyřeší jednou a pořádně, než když to každý umělec bastlí sám, narychlo a nevyhnutelně blbě.
-
To je jenom 57x vice? A predpokladam ze meli vice nez 57 part-time programatoru nasazenych za poslednich 10 let. Takze jejich produktivita je.. rozhodne mensi nez moje (a tohle bylo jenom C, co jsem nastekal v PHP bude i delsi, ale neni to tak uceleny).
A ted sis krasne nabehl - protoze JPEG bylo neco co jsem si implementoval sam. A proc? Protoze typicka distribucni libjpeg.so umi jenom 8-bit obrazky (baseline profil) a ja potreboval pracovat s temi co patri pod extended profile a lossless jpeg format.
Vsechny tri profily jsou popsany ve stejne ITU specifikaci - ale nekdo, kdo se to rozhodl implementovat pro Linux to navrhl od pocatku spatne: pred kompilaci si musite zvolit zda jsou pixely 8bit nebo 16bit, takze vam to rozese*e cele API. Takto se pisou sdilene knihovny? jako fakt ne jako, tohle pouzivat odmitam, navic to tenkrat nemelo akceleraci pro extended a lossless snad zcela chybel.
-
Knihovny vam jsou k nicemu, kdyz bude casem plan to posunout na GPU nebo FPGA - seznamit se s problemem je potreba tak jako tak.
A zrovna to lossless je otazka na par radku: prediktor + huffman. Neni nad to, si implementovat standard z pocatku devadesatek... tech par dekad tomu hodne pomaha a ve svete dnesnich kodeku to je zcela primitivni :)
Btw me jde o Lossless JPEG profil z ITU T.81 (puvodni JPEG standard, 1993) .. nekdy oznacovan jako LJ92 a neni to to same jako JPEG-LS (ITU T.87) - ktery se prakticky neuchytil/nepouziva (na ktery jste zrejme odkazoval/nasel vy).
-
Pamatovat si neco o 350kLoC je neco jineho nez pamatovat si to o 100MLoC.
Jak sem psal - Chromium resi vykon a proto se nektere veci musi delat jinak nez programatorsky optimalne.Zrejme ti nikdo nehleda v kodu zranitelnosti. Pady jsou o tom, co se deje velmi casto. O rad vice je bugu, ktere tam jsou a projevi se jen u opakovaneho specifickeho poradi volani z vicero vlaken nebo tak neco. Vetsinou jde o bugy, kde se treba i nekdo zamyslel nad treba data race, napsali se testy, ale nezohlednil se nektery pripad.
-
Super názor!
Já si to myslím taky. Navíc je třeba si uvědomit, že prohlížeč není jen o C++ - prohlížeč vlastně sahá na všechno - grafika, zvuk, síť, filesystem, dnes i multiprocess a rychlé IPC, hodně OS specific věcí, které stejně mají C-API - tam jiný jazyk vůbec nepomůže - pokud mám nějaký handle, tak ho můžu leaknout nebo předčasně zavřít z kteréhokoliv jazyka a je průser. Navíc je tam JS engine, který má GC a potřebuje držet reference na objekty v C++ (třeba DOM nebo různé rendering contexty atd). Je to celé hodně komplikované a třeba doteď nevidím benefit Rustu ve Firefoxu.
Dnes máme v C++ mnohem větší možnosti než 10 let dozadu - milion druhů sanitizérů, atd... Důležité je testovat. Jasně, Rust je super, ale není to žádná spása...
