<story><title>C2Rust: translate C into Rust code</title><url>https://c2rust.com/</url></story><parent_chain><item><author>Animats</author><text>This is compiling C into very unsafe Rust as a target language:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    pub unsafe extern &amp;quot;C&amp;quot; fn insertion_sort(n: libc::c_int, p: *mut libc::c_int)
 -&amp;gt; () {
        let mut i: libc::c_int = 1i32;
        while i &amp;lt; n {
            let tmp: libc::c_int = *p.offset(i as isize);
            let mut j: libc::c_int = i;
            while j &amp;gt; 0i32 &amp;amp;&amp;amp; *p.offset((j - 1i32) as isize) &amp;gt; tmp {
                *p.offset(j as isize) = *p.offset((j - 1i32) as isize);
                j -= 1
            }
            *p.offset(j as isize) = tmp;
            i += 1
        };
    }
&lt;/code&gt;&lt;/pre&gt;
The output is unmaintainable, like the output from a compiler. This isn&amp;#x27;t translation into usable Rust.&lt;p&gt;A C++ to Rust translator would be a good thing, but it has to be much smarter than this.  This doesn&amp;#x27;t even comprehend arrays in C.&lt;p&gt;A good translator might need some human help to deal with C&amp;#x27;s ambiguities.  Like &amp;quot;Is this an array? (Y or N)&amp;quot;  How big is it?  (Enter expression). Then you get a program that&amp;#x27;s real Rust.  If the user is wrong about the size, safe Rust will either allocate too much space or get a subscript error.</text></item></parent_chain><comment><author>dbaupp</author><text>I know and agree that unsafe Rust is problematic, but that criticism of this is missing the forest for the trees. The original code is just as unsafe.&lt;p&gt;Refactoring from unsafe Rust into safe Rust manually is likely to be easier than directly from C into Rust: one is only trying to deal with one small delta (like changing length&amp;#x2F;pointer arguments into a slice) rather than also having to deal with syntax changes and tooling issues.&lt;p&gt;As others have said, it is essentially impossible to automatically translate to safe Rust without non-trivial annotation effort, since C the language and C in practice is very different to how Rust guarantees safety. It seems to me that that &amp;quot;annotation&amp;quot; effort is probably better spent going unsafe to safe Rust (where, subjectively, the language is nicer to use, like better enums and less error prone control flow) rather than annotating the original C.</text></comment>
<story><title>C2Rust: translate C into Rust code</title><url>https://c2rust.com/</url></story><parent_chain><item><author>Animats</author><text>This is compiling C into very unsafe Rust as a target language:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    pub unsafe extern &amp;quot;C&amp;quot; fn insertion_sort(n: libc::c_int, p: *mut libc::c_int)
 -&amp;gt; () {
        let mut i: libc::c_int = 1i32;
        while i &amp;lt; n {
            let tmp: libc::c_int = *p.offset(i as isize);
            let mut j: libc::c_int = i;
            while j &amp;gt; 0i32 &amp;amp;&amp;amp; *p.offset((j - 1i32) as isize) &amp;gt; tmp {
                *p.offset(j as isize) = *p.offset((j - 1i32) as isize);
                j -= 1
            }
            *p.offset(j as isize) = tmp;
            i += 1
        };
    }
&lt;/code&gt;&lt;/pre&gt;
The output is unmaintainable, like the output from a compiler. This isn&amp;#x27;t translation into usable Rust.&lt;p&gt;A C++ to Rust translator would be a good thing, but it has to be much smarter than this.  This doesn&amp;#x27;t even comprehend arrays in C.&lt;p&gt;A good translator might need some human help to deal with C&amp;#x27;s ambiguities.  Like &amp;quot;Is this an array? (Y or N)&amp;quot;  How big is it?  (Enter expression). Then you get a program that&amp;#x27;s real Rust.  If the user is wrong about the size, safe Rust will either allocate too much space or get a subscript error.</text></item></parent_chain><comment><author>bluejekyll</author><text>&amp;gt; This is compiling C into very unsafe Rust as a target language&lt;p&gt;It’s basically as safe as the original.&lt;p&gt;&amp;gt; This isn&amp;#x27;t translation into usable Rust&lt;p&gt;It’s slightly more usable, and easier, than FFI to raw C (see other comments about Cargo integration).&lt;p&gt;I’ve been thinking about language rewrites like this, and generally I’m really torn. If it’s the intention to get rid of your C, it might in fact be easier to use bindgen for the C header translation, and create decent Rustful interfaces that abstract the C. After that maybe use this tool as a starting point to get Rust or possibly just rewrite the section by hand. In either case you’ll be rewriting the logic into safe Rust at some point, otherwise I don’t see a huge point in doing this (other than the Cargo integration, though there are other options for that).</text></comment>