SaferCPlusPlus-AutoTranslation2 VS llvm-project-deluge

Hi pizlonator, I'm working on a solution with similar goals (I think), but a bit of a different approach. It's a tool that auto-translates[1] (reasonable) C code to a memory-safe subset of C++. The goal is to get it reliable enough that it can be simply inserted as an (optional) build step, so that the source code can be maintained in its original form.

I'm under the impression that you're more of a low-level/compiler person, but I suggest that a higher level language like (a memory-safe subset of) C++ actually makes for a more desirable "intermediate representation" language, as it's amenable to maintaining information about the "intent" of the code, which can be helpful for optimization. It also allows programmers to provide manually optimized memory-safe implementations for performance-critical parts of the code.

The memory-safe subset of C++ is somewhat analogous to Rust's in terms of performance and in that it depends on a non-trivial static checker, but it imposes less onerous restrictions than Rust on single-threaded code.

The auto-translation tool already does the non-trivial (optimization) task of determining whether any (raw) pointer is being used as an array iterator or not. But further work to make the resulting code more performance optimal is needed. The task of optimizing a high-level "intermediate representation" language like (memory-safe) C++ is roughly analogous to optimizing lower-level IR languages, but the results should be more effective because you have more information about the original code, right?

I think this project could greatly benefit from the kind of effort you've displayed in yours.

[1]: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Part of the reason the proposed static analyzer has to be so ambitious is because it's trying to validate (i.e. verify as safe) as much existing/legacy code as possible. An alternative approach is to autoconvert existing code to new code that is easier to verify as safe. One advantage of this approach is that in instances where you cannot (yet) statically verify safety, you can convert to (new) elements that may resort to run-time safety mechanism when necessary. With access to the full range of safety-performance tradeoffs, this approach can (fully) safen a much larger set of legacy code then any static analyzer alone could.

There's also some support for autoconverting legacy C code that is not performance critical to use the library and conform to a safe subset of C++.

Fil-C sounds like an amazing project!

Do you have any guesses on whether it could easily target WebAssembly?

link: https://github.com/pizlonator/llvm-project-deluge/blob/delug...

Or you could just use memory-safe OpenSSL.

https://github.com/pizlonator/deluded-openssl-3.2.0

It's based on Fil-C https://github.com/pizlonator/llvm-project-deluge/blob/delug...

There's no unsafe code in it. The whole thing is recompiled with Fil-C. Works well enough that I can run a memory-safe curl and a memory-safe ssh.

See here: https://github.com/pizlonator/llvm-project-deluge/blob/delug...

I just got the OpenSSH client to work last night.

Here's an example of the kinds of changes you have to make: https://github.com/pizlonator/deluded-openssh-portable/commi...

Most of the changes are just using zalloc and friends instead of malloc and friends. If I reaaaallly wanted to, I could have made it automatic (like, `malloc(sizeof(Foo))` could be interpreted by the compiler as being just `zalloc(Foo, 1)` ... I didn't do that because I sorta think it's too magical and C programmers don't like too much magic).