105 comments
wffurr · 16 hours ago
Note that this is done for “existing formally verified C codebases” which is a lot different from typical systems C code which is not formally verified.

Show replies

amenghra · 7 hours ago
In 2002, a group of researchers presented a paper on Cyclone, a safe dialect of C [1]. While (manually) porting code from C to Cyclone, they found safety bugs in the C code.

These kinds of manual or automated conversation from C to <safer language> therefore have potential not only for increasing adoption of safer languages but also for uncovering existing bugs.

[1] https://www.researchgate.net/profile/James-Cheney-2/publicat...

alkonaut · 7 hours ago
If you used a naïve translation to Rust, wouldn’t you get parts that are safe and parts that are unsafe? So your manual job would need to be only verifying safety in the unsafe regions (same as when writing rust to begin with)?

Seems it would be a win even if the unsafe portion is quite large. Obviously not of it’s 90% of the end result.

Show replies

pizlonator · 15 hours ago
Compiling a tiny subset of C, that is. It might be so tiny as to be useless in practice.

I have low hopes for this kind of approach; it’s sure to hit the limits of what’s possible with static analysis of C code. Also, choosing Rust as the target makes the problem unnecessarily hard because Rust’s ownership model is so foreign to how real C programs work.

Show replies

zoom6628 · 10 hours ago
I wonder how this compares to the zig-to-C translate function.

Zig seems to be awesome at creating mixed environs of zig for new code and C for old, and translating or interop, plus being a C compiler.

There must be some very good reasons why Linux kernel maintainers aren't looking to zig as a C replacement rather than Rust.

I don't know enough to even speculate so would appreciate those with more knowledge and experiencing weighing in.

Show replies