Comment by Panzerschrek
2 days ago
The main problem of Fil-C or similar solutions is not that they provide absolute safety with no escape hatch (unlike languages with unsafe keyword). The problem is that they provide an excuse to keep using terrible programming languages like C and C++ allowing memory safety issues in the first place.
But if you're using Fil-C is it still a memory safety issue or just an ordinary crash bug?
Yeah, but who's going to rewrite LLVM in Rust, which rustc relies on?
Yes there is Cranelift, and?
In case of such projects like LLVM C++ usage can be tolerated. But for new code or smaller codebases a better alternative should be considered.
Also Fil-C can't be used for LLVM anyway, since performance and memory consumption overhead is way too much. Nobody wants clang/rustc working 4x slower and consuming 2x more memory.
Yeah, unfortunately there are plenty of such projects, without alternatives.
GCC, GNOME, KDE, Linux kernel, BSD variants, CUDA, RocM, OpenCL Vulkan, DirectX, Metal, GNM(X), OpenMP, OpenACC, NVN,....
Hence why somehow fixing C and C++ is also quite relevant for the upcoming decades, assuming humans still matter on the planet.
Now it is going to be ARM MTE, SPARC ADI, CHERI, Fil-C, or WG14 and WG21 actually getting their act together, remains to be seen, as it is subject to governments and industry pressure, and we not destroying civilisation.
2 replies →