4 ms·

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.

levodelellis 1y ago
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
- deleted 1y ago
  [deleted]
- uecker 1y ago
  The memory model of C is intentionally designed to allow safe implementations (still from the time of hardware-segmented methods).
  - CoastalCoder 1y ago
    Could you expand on that?
    - aw1621107 1y ago
      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.
      - uecker 1y ago
        Even more, certain rules are specifically designed to make such checks possible while being conformant to the standard.
      - pornel 1y ago
        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.
- timeon 1y ago
  > proper compiler Not just compiler but GC as sell. So it does note solve same problem as Rust.
  - levodelellis 1y ago
    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
    - timeon 1y ago
      > 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.
      - levodelellis 1y ago
        [flagged]
- Ar-Curunir 1y ago
  It is well known that GC allows you to solve memory safety problems
- Mond_ 1y ago
  ? 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.
ralegh 1y ago
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.
- Animats 1y ago
  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.
stared 1y ago
Tried Claude Code with explicit instructions to create idiomatic code and avoid unsafe statements?
jrpelkonen 1y ago
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-c2rust https://tweedegolf.nl/en/blog/151/translating-bzip2-with-c2r...
- pizlonator 1y ago
  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.
  - galangalalgol 1y ago
    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.
    - pizlonator 1y ago
      > 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
      - galangalalgol 1y ago
        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.
kevincox 1y ago
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.

levodelellis 1y ago

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

deleted 1y ago
[deleted]
uecker 1y ago
The memory model of C is intentionally designed to allow safe implementations (still from the time of hardware-segmented methods).
- CoastalCoder 1y ago
  Could you expand on that?
  - aw1621107 1y ago
    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.
    - uecker 1y ago
      Even more, certain rules are specifically designed to make such checks possible while being conformant to the standard.
    - pornel 1y ago
      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.
timeon 1y ago
> proper compiler Not just compiler but GC as sell. So it does note solve same problem as Rust.
- levodelellis 1y ago
  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
  - timeon 1y ago
    > 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.
    - levodelellis 1y ago
      [flagged]
Ar-Curunir 1y ago
It is well known that GC allows you to solve memory safety problems
Mond_ 1y ago
? 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.

ralegh 1y ago

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.

Animats 1y ago
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.

stared 1y ago

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

jrpelkonen 1y ago

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-c2rust https://tweedegolf.nl/en/blog/151/translating-bzip2-with-c2r...

pizlonator 1y ago
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.
- galangalalgol 1y ago
  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.
  - pizlonator 1y ago
    > 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
    - galangalalgol 1y ago
      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.

kevincox 1y ago

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.