(no title)
joe-user | 2 days ago
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
josephg|2 days ago
Yeah this is where I stand with it. Fil-C seems to be the worst of all worlds. It combines the performance of an immature GC language, with the primitive syntax and ecosystem of C. (Eg nullability, void*, no generics, no collection types, a bad standard library, header files, no good build system, bad cross-OS portability, BYO strings, etc).
I don't choose C for its wonderful syntax. I choose it because its small, light and performant. If I was happy to use a garbage collector, I'd much prefer to go all the way and grab Typescript, C# or Go.
The only use case I can see for Fil-C is running legacy code that you can't be bothered porting to a better language.
dgrunwald|1 day ago
It's especially problematic to have multiple different garbage collectors; so given the desire to reuse libraries across language boundaries, there's still a strong demand for Yolo-C, C++ or Rust.
maxbond|2 days ago