Hacker News Reader

Comment by pizlonator | Hacker News Reader

The code I've seen that was autotranslated from C to Rust has an absolutely hopeless number of unsafe statements.

You're better off using Fil-C.

Fil-C is an innovative approach and a great technical achievement. However, I wouldn't suggest that it is an universal solution without caveats. For instance, the performance penalty of up to 4x is not acceptable in a lot of cases.

Also, the c2rust output is rough but not hopeless: There are real world success stories of rust projects that were bootstrapped via c2rust, e.g. https://tweedegolf.nl/en/blog/151/translating-bzip2-with-c2r...

bzip2 is tiny, has relatively low overhead in Fil-C (forget exactly what it is but not 4x), and last I checked this Rust version still has >100 uses of unsafe.

Fil-C doesn't stop the data race problems the borrow checker would catch does it?

Has anyone tried pointing an agentic ai at recreating a c utility by looking only at the man page and using differential fuzzing? It isn't a port, so no licensing issues, and the code would use unsafe, and presumably be more idiomatic. I have no idea if it would ever complete, or just get stuck in an endless loop. Or even if it did succeed, how many joules it would use.

> data race problems

No, Fil-C just makes races memory safe.

Also this is sort of changing the topic a bit since bzip is single threaded

Even if it wasn't single threaded, it would probably have been fine grained OMP style multithreaded which runs into far fewer issues. I was just making sure I understood what Fil-C was doing. I hadn't heard of it. It seems like a great thing.

I'm sure when you try to get a AI to recreate such a tool, ths code would be unmaintainable, bloath, slow and shitty, but in the end it would work in some way. Interesting topic, but nothing to go productive with.

Are they competing with WASM on performance?

I would assume that these two use cases are basically completely separate.

Auto-translate from C to Rust would serve as a great step to starting a porting project. Now you can incrementally re-write the "basically C" auto-ported code to "proper Rust" without dealing with FFI and other pains that come from function-by-function ports.

Fil-C is great for running software that you don't want to port. (Or don't yet have the resources to port.)

Interestingly there is probably a gap between the two. When your project is pure C you can use Fil-C. However I don't think Fil-C supports Rust. So assuming that the initial C to Rust translation doesn't produce 100% safe code (I'm not aware of any current tools that do this) you have this middle state where you can no longer compile with Fil-C but have lots of unsafe Rust code. So maybe there is a use case for Fil-Rust where you compile your Rust program so that even unsafe blocks are in fact safe. This could be used until you complete the port.

Wonder if it would be better to auto translate to broken rust, ie forcing the user to fix memory issues. I imagine that would lead to pretty big refactors in some cases though.

No. What comes out of C2Rust is awful. The Rust that comes out reads like compiler output. Basically, they have a library of unsafe Rust functions that emulate C semantics. Put in C that crashes, get Rust that crashes in the same way. Tried that on a JPEG 2000 decoder.

I find it funny AF that Fil-C is safer than languages with the unsafe keyword. Who knew C could be so safe with a proper compiler

The memory model of C is intentionally designed to allow safe implementations (still from the time of hardware-segmented methods).

Could you expand on that?

I believe the claim is that there's nothing in the C standard that requires implementations to be unsafe. If they wanted to, they could bounds check pointers, check allocations are still alive when pointers are dereferenced, etc. and still be conformant to the standard.

Even more, certain rules are specifically designed to make such checks possible while being conformant to the standard.

Nothing in the C standard requires bytes to have 8 bits either.

There's a massive gap between what C allows, and what real C codebases can tolerate.

In practice, you don't have room to store lengths along pointers without disturbing sizeof and pointer<>integer casts. Fil-C and ASAN need to smuggle that information out of band.

> proper compiler

Not just compiler but GC as sell. So it does note solve same problem as Rust.

Would you rather have a gc or unsafe?

In just about every language I seen people use .clone rather than deal with problems so I suspect a lot of cases a GC can be just fine or faster. Although I'm comfortable with memory management and rather use C or C++ if I'm writing fast code

> Would you rather have a gc or unsafe?

Like in case where you can't use Rust? (ie.: existing codebase). Sure that is what Fil-C is good for. Point is that Fil-C does not solve the problem Rust does. It is more like band-aid. (Maybe my comment was misunderstood because of typo: sell/well)

Also I think there is huge difference between GC and fact that some people use .clone() somewhere.

It is well known that GC allows you to solve memory safety problems

? Putting a program into a safe container or isolation boundary (this is roughly what GC is in this context) causes it to be memory safe. This is not an interesting observation. It also causes it to be significantly slower, to the point of not being competitive anymore.

Tried Claude Code with explicit instructions to create idiomatic code and avoid unsafe statements?

Reply on news.ycombinator.com