| > Are you saying you somehow inhibit the optimizer from injecting a security vulnerability due to UB ala https://www.cve.org/CVERecord?id=CVE-2009-1897 ? I’m kinda curious how you trick LLVM into not optimizing through UB since it’s UB model is so tuned to the C/C++ standard. Yes that is inhibited. There’s no trick. LLVM (and other compilers) choose to do those stupid things by policy, and the policy can be turned off. It’s not even hard to do it. > Fil-C is more an independent dialect of C/C++ (eg you do have to patch some existing software) Fil-C is not a dialect. The patches are similar to what you’d have to do if you were porting a C program to a new CPU architecture or a different compiler. > By this argument no language is memory safe because every language has bugs that can result in memory safety issues. You rebutted this argument for me: > any safety issues within the language spec or implementation are a bug to be fixed Exactly this. A memory safe language implementation treats outstanding memory safety issues as a bug to be fixed. This is what makes almost all JS implementations, and Fil-C, memory safe. |