c2rust VS zz

A recent practical example of the former: the fish shell re-wrote incrementally from C++ to Rust, and is almost finished https://github.com/fish-shell/fish-shell/discussions/10123

An example of the latter: c2rust, which is a work in progress but is very impressive https://github.com/immunant/c2rust

It currently translates into unsafe Rust, but the strategy is to separate the "compile C to unsafe Rust" steps and the "compile unsafe Rust to safe Rust" steps. As I see it, as it makes the overall task simpler, allows for more user freedom, and makes the latter potentially useful even for non-transpiled code. https://immunant.com/blog/2023/03/lifting/

But not all transpilers are between languages where at least one of them is designed to be transpiled. For example, c2rust can transpile, as the name suggests, C to (ugly, unsafe) Rust. A while ago there was a Java -> C compiler in GCC (GCJ), but it's pretty out of date now.

I do not know about your specific issue but you may be interested by https://github.com/immunant/c2rust

You should also consider using C2Rust (they're even working on C -> safe Rust translation)

> The date at the bottom of the article is 2022-06-13. Has there been further progress?

The article links to their github repo:

https://github.com/immunant/c2rust

There's commits in the last hour, so at least some signal of life.

This is arguably already the state of things.

Rust might get compiled down through MIR, down through LLVM IR, down to assembly or wasm... which then might be JIT or AOT (re)compiled into other bytecodes... which might perhaps be decompiled back up to C... and C might be retranslated back to horrific unsafe-spamming Rust by the likes of https://c2rust.com/. We've come full circle!

The main issue is that retranslating high level languages into other high level languages isn't something that there's actually a lot of demand for, especially commercially, especially given the N x M translation matrix going on. So a lot of the projects "stabilize" (get abandoned). And automatically translating between the idioms of those languages gets even nastier in terms of matrix bloat.

Well, you've got stuff like MSIL and JVM bytecodes which are higher level, and preserve more type information, and can be compiled to / decompiled from while still preserving more structure, but they still form competing incompatible ecosystems.

That's the wrong direction. What's needed are intelligent converters which convert less-strict languages to more-strict ones.

Non-intelligent converters just make a mess. Here's c2rust.[1]

Classic C++ to modern C++, plus a compiler flag to lock out all the old unsafe stuff, would be an achievement.

[1] https://c2rust.com/

Well, technically, it's not hard to build such data structures. If you are willing to liberally use raw pointers, UnsafeCell, MaybeUninit and ManuallyDrop, then you can more-or-less write C-equivalent code in unsafe Rust. (there are even transpilers from C to Rust)

/uj This transpiles from C to unsafe Rust using an existing tool, then strips the unsafe keyword from the generated function signatures

> we'll find out Rust isn't the panacea to all our language problems

I don't think anyone is suggesting it will be. It's not about to supplant Ada SPARK, for instance, as Rust is far behind in terms of formal analysis.

> just like what the parent pointed out about Java and it's memory safety promises back in the day

Java does address the memory-safety issues of C and C++. You can't have a buffer overflow vulnerability in pure Java code. You can't have any kind of undefined behaviour due to memory-management mistakes in your code. You can't double-free, or use-after-free, or deference a pointer to a local variable that has gone out of scope. You can't trigger undefined behaviour through a read-before-write bug in your code.

It's possible to have a memory leak in Java, if you retain references to objects for too long, but that won't ever give rise to undefined behaviour.

Of course, there can still be bugs in a JVM, but that's another matter. All languages are vulnerable to compiler bugs.

Other languages like JavaScript do the same. It's possible to leak memory, but it's never possible to trigger undefined behaviour from JavaScript. That's a vital part of its security model.

> It is indeed quite possible to write memory safe C/C++ code... and it's done every day

That doesn't sound right.

There's a reason I gave the examples of the Linux kernel and Chromium. They're written by highly competent developers, but they still have subtle memory-management bugs. Most C/C++ codebases are written by less competent developers, but are of far less interest to attackers, so it's of less consequence. Their memory-management bugs are likely to go unnoticed forever.

I agree it's possible to write C/C++ code without memory-management bugs (there are various formal development systems for C), but it's a significant challenge. I'd hope avionics software, for instance, would be entirely free of such bugs.

> You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes.

They're not that rare, they're a major source of serious security vulnerabilities, and languages like Safe Rust can close the door on them entirely.

> The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore!

Agreed. C++ is quite a lumbering monster of complexity. Ada also has a reputation for being somewhat bloated, but it's not as far gone as C++.

> if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has

Keep an eye on Zig, too. Also D and Nim, and perhaps Vala. Also the lesser-known ZZ language, which looks very interesting.

https://github.com/aep/zz