Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C2Rust: translate C into Rust code

c2rust.com

Post reply on HN
Print view View original

61–70 of 79 posts

Re: C2Rust: translate C into Rust code

#61

Post by stefan_ »

dbaupp wrote: post #53
Animats wrote: post #24

This is compiling C into very unsafe Rust as a target language: pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) -> () { let mut i: libc::c_int = 1i32; while i 0i32 && *p.offset((j - 1i32) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1i32) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; } The output is unmaintainable, like the output from a compiler. This isn't trans…

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. 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/pointer arguments into a slice) rather than also having to deal with syntax changes and too…

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

Re: C2Rust: translate C into Rust code

#62

Post by dbaupp »

stefan_ wrote: post #61
dbaupp wrote: post #53

Earlier quoted context omitted.

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. 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/pointer arguments into a slice) rather than also having to deal with syntax changes and too…

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at compile time or runtime, no matter how incorrect the program/use of the API is. Just like C, it is an incorrect Rust program if undefined behaviour actually happens, meaning all uses of `unsafe` have to actually be safe, but it's up to the programmer to ensure this, with less compiler assistance than in normal Rust.

Every single pointer access `*p` or `p[i]` in C has potential for undefined behaviour (e.g. p is NULL, points to an invalid object, or i is out of bounds), and thus the Rust equivalent is surfacing this risk in a more obvious way.

Re: C2Rust: translate C into Rust code

#63

Post by gue5t »

stefan_ wrote: post #61
dbaupp wrote: post #53

Earlier quoted context omitted.

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. 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/pointer arguments into a slice) rather than also having to deal with syntax changes and too…

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

In the context of Rust, unsafe does not mean incorrect or vulnerable to memory unsafety. Unsafe refers to code whose memory safety has not been proven (by the compiler's static analysis based on ownership and lifetimes, given the assumption of correctness of other unsafe code (so you can look at the proof of memory safety of a program as a whole as an inductive tree of proofs, with the leaves being unsafe code like in `std::Vec`, which is subject to formal and practical scrutiny outside of rustc's static analysis).

By this definition, all C code has unsafe memory accesses. However, it is possible to define static analyses that can prove memory safety of some portions of C programs, and incorporating such a thing into C2Rust would allow it to generate more safe Rust and less unsafe Rust.

Re: C2Rust: translate C into Rust code

#64

Post by dbaupp »

dbaupp wrote: post #62
stefan_ wrote: post #61

Earlier quoted context omitted.

I think it is you missing the forest for the trees. The majority of C code does not in fact have unsafe memory accesses. So clearly we have a problem here with the translator being too stupid or the language; neither is something I look for in a tool I use.

No, all memory accesses in C are unsafe in the keyword-in-Rust sense: `unsafe` indicates that an API can be misused to cause undefined behaviour, contrasting to non-`unsafe` code where any potential undefined behaviours will be caught at compile time or runtime, no matter how incorrect the program/use of the API is. Just like C, it is an incorrect Rust program if undefined behaviour actually happens, meaning all uses…

(It would have been clearer if my original comment said: "The C and the Rust both risk undefined behaviour in the same ways", instead of using an overloaded meaning of unsafe in saying that the C is unsafe.)

Re: C2Rust: translate C into Rust code

#65

Post by steveklabnik »

wtetzner wrote: post #58
floatboth wrote: post #57

Earlier quoted context omitted.

That only applies to shared libraries. If the crate builds the library and links it statically, you don't see the tooling.

Don't you still need C tooling setup for the crate to build the C library? Especially on Windows, this can be a pain.

On Windows, if you’re using the MSVC version, which we recommend, then you’ll have that tooling installed anyway; it’s the only way to get link.exe.

Re: C2Rust: translate C into Rust code

#66

Post by amelius »

dbaupp wrote: post #53
Animats wrote: post #24

This is compiling C into very unsafe Rust as a target language: pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) -> () { let mut i: libc::c_int = 1i32; while i 0i32 && *p.offset((j - 1i32) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1i32) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; } The output is unmaintainable, like the output from a compiler. This isn't trans…

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. 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/pointer arguments into a slice) rather than also having to deal with syntax changes and too…

> The original code is just as unsafe.

But the translated code being unreadable to humans adds a whole new layer of "unsafe".

Re: C2Rust: translate C into Rust code

#67

Post by brian_herman »

glguy wrote: post #33
brian_herman wrote: post #31

#define a "xxxxxxxxxxx" #define b a a a a a a a #define c b b b b b b b #define d c c c c c c c #define e d d d d d d d #define f e e e e e e e #define g f f f f f f f #define h g g g g g g g #define i h h h h h h h #define j i i i i i i i main(){char*z=j;} This fails. The error is entity not found.

There are definitely ways to overwhelm the translator web demo. I know I'm not clever enough to block all of them. I put the page up to give people a way to try out the translator without having to build it. Please don't kill it :-)

Oh sorry

Re: C2Rust: translate C into Rust code

#69

Post by platinumrad »

dbaupp wrote: post #53
Animats wrote: post #24

This is compiling C into very unsafe Rust as a target language: pub unsafe extern "C" fn insertion_sort(n: libc::c_int, p: *mut libc::c_int) -> () { let mut i: libc::c_int = 1i32; while i 0i32 && *p.offset((j - 1i32) as isize) > tmp { *p.offset(j as isize) = *p.offset((j - 1i32) as isize); j -= 1 } *p.offset(j as isize) = tmp; i += 1 }; } The output is unmaintainable, like the output from a compiler. This isn't trans…

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. 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/pointer arguments into a slice) rather than also having to deal with syntax changes and too…

>The original code is just as unsafe.

That assumes zero translation errors as well as the original C code not relying on a particular compiler's specific implementation of unspecified behavior.

Re: C2Rust: translate C into Rust code

#70

Post by lomnakkus »

masklinn wrote: post #18
taneq wrote: post #11

Earlier quoted context omitted.

Sounds like a case of "writing C in Rust" compared with "writing Rust". You're not really writing in a language until you're thinking in its idioms.

> Sounds like a case of "writing C in Rust" compared with "writing Rust". Duh? It's literally taking C code and generating Rust code which behaves the same. > You're not really writing in a language until you're thinking in its idioms. The entire point is to get your foot in the door. This gives you a pile of Rust code which (bugs aside) should behave the exact same way C code does. From there on you're living in the…

> If you can afford doing the initial transition in one short, later improvements are much simpler than having to maintain an internal (moving) front between remaining C code and new Rust code as e.g. librsvg does.

That's all well and good... if you don't have to maintain the project while doing the necessary C-as-Rust -> "proper" Rust conversion. This C-as-Rust output seems[1] like it woul d be incredibly difficult to do bugfixes in and there's also the issue of what happens if the C code happened to rely on implementation-defined behavior (or even UB which the implementation happens to "do the right thing" with).

Unless you have a trivial amount of code, I'd say the right thing is to do the conversion in small chunks. This also gives you a much better way to ensure (through test suites) that you're not introducing excessively many new bugs when rewriting C-as-Rust to "proper" Rust.

[1] I realize this is early days, but I'm talking about the present time.

Post reply on HN