To jde i v C a C++, když je přeložíte třeba Fil-C, pokud nechcete měnit kód.
A pokud nevadí měnit kód, tak ho jde napsat, aby těch zranitelností bylo méně. Třeba nepoužívat RAII a nespravovat paměť po jednotlivých hodnotách, ale po skupinách hodnot. Naívc takto napsaný kód poběží rychleji než typický kód v Rustu, kde typicky musíte ledacos zbytečně kopírovat, aby se uspokojily požadavky borrow checkeru.
A kolikrát víc paměti a výkonu potřebuje Fil-C?
To se nedá srovnat - Fil-C je v kategorii sanitizer, takže něco pro debug a ne deployment.
> A kolikrát víc paměti a výkonu potřebuje Fil-C?
V současné době asi hodně. Odhad autora do budoucna je "somewhere between 1.02x and 2x"
Na druhé straně je to ale bezpečnější než Rust, protože skutečného unsafe kódu tam máte o dost méně.
Unsafe kódu je tam úplně stejně jako v C, protože Fil-C je sanitizér, který dělá kontroly za běhu.
Toto se fakt nedá vůbec srovnat. Rust má výkon, Fil-C ne.
> Fil-C je sanitizér, který dělá kontroly za běhu.
Kontroly dělá za běhu, ale cíl je, aby se to normálně používalo v produkci - tj. aby to bylo rychlé.
Jenže ryché to není - potřebuje to extra paměť a dělá to extra kontroly u všeho možného a nemožného.
Ok, pro stávající kód je to asi cesta, ale co se týče nových věcí, jaká je výhoda v přidání Garbage Collectoru k C oproti prostě použití GC jazyka jako Golang?
Fil-C by mělo být bezpečnější. Třeba pro nějaké nízkoúrovňové věci potřebujete v Go unsafe package. Ve Fil-C většina z těhle věcí bude safe. Podobně v Rustu je hodně datových struktur napsáno v unsafe kódu, ve Fil-C by byly safe.
Navíc, pokud v Go nebo Rustu voláte C/C++ kód, tak riskujete, že to nebude paměťově bezpečné. U Fil-C můžete zkusit i volaný kód přeložit, a pokud se to povede, tak bude memory safe.
To nedává smysl.
Proč psát unsafe kód, který nějaké "runtime" sanitizer bude kontrolovat za cenu až čtyřnásobného zpomalení, když může psát safe kód (rust), který ve většině případech žádným zpomalením netrpí.
Toto není cesta nikam, nedává to smysl.
To dava smysl. Protoze mate kod existující a nikdo ho zadarmo neprepise. HW je levnejsi nez lidska prace. 4x penalizace neni nic. Rada projektu jede treba s 50x ci 200x penalizaci a porad se vyplati .
A AI optimizer taky nekdo musi kontrolovat ze?
Takže prechod na Rust priniesol tak neuveriteľné množstvo bugov, že sa nejaké pamäťové chyby v húšti ľahko stratia.
A vis to ze za presne takovouhle "statistiku" bys dostal maximalne za 5?
Nevis? Ok ... pocet chyb narostl na tisicinasobek ... pomer tech pametovych klesl na 20% (ale celkovy pocet narostl 100x) ... presne odpovida tomu plku.
BTW: Nemelo by se nahodou guuglu zakazat vydavat jakejkoli SW? Kdyz se rusil flash, tak prej proto, ze byl deravej jak reseto. Vytvory guuglu jsou mnohem deravejsi.
Dát za příklad flash, to chce odvahu. Flash byl co se týče bezpečnosti asi to nejhorší, co na webu kdy bylo.
Doporučuju přečíst si původní report, ať tu další lidi nepíšou, že je v rustu asi víc ostatních chyb.
Ten report je docela zajímavý. Vychází jim, že rust kód se rollbackuje 4x méně, než c++ kód. Přitom kód reviews trvají kratší dobu. A taky jim vychází, že v unsafe rustu je o několik řádů méně chyb, než v normálním c++ kódů. Což odporuje relativně častému tvrzení, že unsafe rust je oproti c++ náchylnější na chyby.