Názory k článku
Práce na Rust Coreutils pokračují, nevzdávají to ani vývojáři, ani Ubuntu

Za zmínku stojí, že pokud někdo chce bezpečnost a kompatibilitu, tak může přeložit klasické Coreutils pomocí Fil-C. Tím ve výsledku dostane memory safety lepší než v Rustu, protože není potřeba žádný unsafe kód a funguje to i pro dynamické linkování.

> není potřeba žádný unsafe kód

Vzato do důsledků, toto neplatí nikdy v žádném jazyce. Ani pro Hello World v JS.

Ano, runtime Fil-C jsem do toho nepočítal. Nicméně třeba už na standardní knihovnu C++ se ty zároky Fil-C vztahují. Což je podstatné zlepšení v memory safety oproti Rustu, kde je standardní knihovna plná unsafe kódu.

To je ochrana v runtime (fuj) ne v compiletime (huj), ne?

Compiletime je, když sedím v kanclu za stolem. Runtime může být, když jsem na dovolené, pár časových pásem ode mě a další radosti.
Něco pokryjou testy a podobně. Ale když se dá něco ošetřit v compiletime, tak je to prostě jednodušší a příjemnější.

Ano, v runtime. Např. jedna z částí té ochrany je, že každý ukazatel má metadata, která vymezují rozsah paměti, kam jde přistupovat, a to se kontroluje při každém použití ukazatele.

Aniž bych chtěl shazovat práci lidí kolem Fil-C, tak to jejich runtime přístup má zase jiné nevýhody. Protože můžou chytit zápisy mimo oprávněný prostor, ale bez sémantických informací (void* toho moc nesděluje) navíc jen hádají. Stejně tak neodhalí chyby souběhu. Jen zareagují, když náhodou nastanou.

Takže ano - je to pak asi bezpečnější z hlediska exploitů. Ale uživatel bude stejně naštvaný, protože program spadne. A ty runtime kontroly taky sníží výkon, což se třeba u coreutils dost řeší.

kdyz se na to narazilo muzete se tesit na wookash podcast kde je autor fil-c a casey muratori jako co-host. videl jsem to nazivo a prislo mi to super zajimavy nejen z hlediska realizace, ale jak vubec pristoupit k podobnymu typu projektu. jen to typicky vezme tak mesic nez to postriha vyda.

Cílem je kompletní memory safety - tady se to autor snaží dotáhnout mnohem dál než v Rustu.

S těmi runtime kontrolami máte pravdu, jenže AFAIK není žádný rozšířený jazyk, který by se tomu vyhnul. I safe Rust ošetřuje různé věci za běhu (např. meze pole, nebo vás nutí zamykat, i když žádný souběh nehrozí, nebo musíte zbytečně klonovat objekty, abyste uspokojil typový systém).

To, že se něco musí dělat v runtime ale není argument pro to, že by se tam mělo dělat všechno.

BTW, memory safety by neměl být cíl ale jen implementační detail na cestě ke spolehlivějšímu softwaru. A pád programu na hubu může být i větší problém, než přístup mimo hranice pole. Záleží na tom, co ten software dělá.

Já to beru jako SW, co nejde tak snadno ovládat útočníkem. Osobně mi nepřijde, že by memory safety korelovala se spolehlivostí.

Memory safety vlastně ani není přesně definována. Např. C program mohu odsimulovat v Rustu uvnitř velkého pole, které bude sloužit jako paměť programu. Je takový program memory safe? A pokud ano, je to k něčemu?

A nemohla by to do Rustu přepsat AI? Baly by to rychlejší.