5 ms·
I don’t buy it but let’s say that in the best case this happens. Then we’ll have a continuation of the memory safety exploit dumpster fire because these Rust p
by pizlonator 1y ago
I don’t buy it but let’s say that in the best case this happens.
Then we’ll have a continuation of the memory safety exploit dumpster fire because these Rust ports tend to use a significant amount of unsafe code.
On the other hand, Fil-C has no unsafe escape hatches.
Think of Fil-C as the more secure but slower/heavier alternative to Rust
- kragen 1y agoHmm, maybe this should be on the project's homepage: recompiling with Fil-C is a more secure but slower and more-memory-consuming alternative to rewriting in Rust.
- pizlonator 1y agoI want to write a detailed post about the strength of Fil-C’s memory safety guarantee at some point. I haven’t yet thought of a sufficiently precise way and sufficiently classy way to say it.
- kragen 1y agoDoes Epic upper management have an opinion?
- CuriouslyC 1y agoBy default you are right. However you can use static analysis and tooling guardrails to reject certain classes of unsafe code automatically, and force the agent to go back to the drawing board. It might take a few tries and a tiny amount of massaging but I don't doubt it'd get there.
- pizlonator 1y agoIf you could get there that way with Rust’s unsafe blocks then you could get there that way with C++
- CuriouslyC 1y agoprobably true. I think thing doing the heavy lifting is an adversarial loop on the generated code to red team it repeatedly before merge.
- baranul 1y agoSeems like this kind of talk might scare certain invested people.