Live data from Hacker News

Corrode: C to Rust translator written in Haskell

github.com

91–100 of 127 posts

Re: Corrode: C to Rust translator written in Haskell

#91
post #88
post #61

Earlier quoted context omitted.

When it comes to connotations, "what people know about" is more important than the intent.

When it comes to connotations, the one's associated with Rust are beyond negligible...

How so? For me, "rust" conjures images of a rusty nail, rust getting in your tap water, a machine in disrepair from rust, and becoming "rusty" at some skill.

And I don't think I'm alone.

Re: Corrode: C to Rust translator written in Haskell

#93

as many "transpilers" / compilers, whatever you might name them, it lacks example input output. I want to see how my new rust code base looks light, does it compile with some heuritics, or just 1:1 C to rust primitives?

Here you go. It didn't like my stdio.h. Apparently enums and unions aren't supported, but: extern int printf(char *, ...); int main(int argc, char argv[]) { printf("Hello, world!\n"); return 0; } Was turned into: extern { fn printf(arg1 : *mut u8, ...) -> i32; } #[no_mangle] pub unsafe fn main(mut argc : i32, mut argv : *mut u8) -> i32 { printf(b"Hello, world!\n\0".as_ptr() as (*mut u8)); 0i32 } edit: Also worth noti…

It transliterates C to Rust all right, but the Rust isn't any safer than the C that goes in. Note the representation of an null-terminated string - it's an unsafe pointer to a byte. That's what it was in C, transliterated unsafely to Rust. Some safe Rust representation for C arrays is needed.

From the description of how it translates a FOR loop, it does so by compiling it down to the primitive operations and tests. A Rust FOR loop does not emerge. That needs idiom recognition for the common cases including, at least, "for (i=0; iThis is a big job, but it's good someone started on it.

Re: Corrode: C to Rust translator written in Haskell

#94
This is the coolest thing I've seen on HN in a long time, and useful to boot. Hopefully this will be a very big help to people moving over to Rust from C for its safety and type-checking. In general I don't support rewrites because, as many experienced programmers have pointed out, rewrites often make many of the same mistakes as the program they're rewriting. But transpilation allows us to keep the code with all the fixes to those mistakes.

In theory I'm a big supporter of Rust. I strongly feel that we should be using stronger-typed languages than C for developing security-critical applications, and from the outside, it looks like Rust solves a lot of my criticisms of C without giving up any benefits of C. A transition over to Rust could be a big win for security and reliability of many systems.

However, I'm reluctant to devote time to learning Rust primarily because it's not supported by GCC (or any other GPL compiler that I know of). I hope the next cool thing that that the Rust community does is to continue the work done by Philip Herron[1] on a Rust front-end for GCC. I know the classic response to this is, "Do it yourself!" but there are too many other areas of Open Source that are higher priorities for me, so sadly this will have to be done by someone else if it happens at all.

[1] https://github.com/redbrain/gccrs

Re: Corrode: C to Rust translator written in Haskell

#95
post #4

The name "Corrode" doesn't seem very positive given the purpose of this program...

Rust is a type of corrosion.

Ironically though the name rust is from the species of fungi https://en.m.wikipedia.org/wiki/Rust_(fungus)

Re: Corrode: C to Rust translator written in Haskell

#96
post #63
post #35

Earlier quoted context omitted.

Shouldn't a C `int` be converted to Rust's `isize`. I think that captures the spirit better.

Not to look a gift horse in the mouth, but it seems like Corrode misses some other chances to use idiomatic Rust: 1. Rust fn:main doesn't need to return something. 2. The arguments to main aren't mutated, so Rust doesn't need to declare them as mutable. 3. Ditto for the argument to printf. Anyone know how easy it is to recognize and code for such cases in the transpiler? Edit: It looks like they might have opposite d…

I think that keeping an exact one-to-one mapping makes this tool a lot more useful. There's no telling what code depends on C idioms that would be broken by using a Rust idiom instead. Generating 100% equivalent code means that programmers can make intelligent decisions about when to switch over to Rust idioms as they continue developing the program.

Re: Corrode: C to Rust translator written in Haskell

#97
post #56

Earlier quoted context omitted.

By "some stupid thing to their headers" are you referring to nullability annotations? I'm not sure what else Apple would have added to pure C headers (as opposed to obj-c) any time in the past few years.

I would like to know, too.

Me too!

Re: Corrode: C to Rust translator written in Haskell

#98
post #66

Earlier quoted context omitted.

As someone who knows zero haskell, and little markdown, can someone explain how this works? haskell.org [1] says there is "bird style" and "LaTeX style" ways of marking off code vs documentation, and I see neither in the linked file. Is it the "```haskell" blocks? [1] https://wiki.haskell.org/Literate_programming#Haskell_and_li...

Yes, that seems to be the syntax used by literate markdown https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown

Just some additional info, because literate markdown support is not completly frictionless yet:

To so this yourself you need to add the --markdown-unlit flag to ghc and add the package "markdown-unlit" to your dependencies. Additionally you have to symlink your .md file to .lhs, as ghc does not look at .md files (even with the --markdown-unlit flag, which I find kinda sad)

Re: Corrode: C to Rust translator written in Haskell

#99
post #66

Earlier quoted context omitted.

As someone who knows zero haskell, and little markdown, can someone explain how this works? haskell.org [1] says there is "bird style" and "LaTeX style" ways of marking off code vs documentation, and I see neither in the linked file. Is it the "```haskell" blocks? [1] https://wiki.haskell.org/Literate_programming#Haskell_and_li...

Yes, that seems to be the syntax used by literate markdown https://ghc.haskell.org/trac/ghc/wiki/LiterateMarkdown

Just some additional info, because literate markdown support is not completly frictionless yet:

To so this yourself you need to add the --markdown-unlit flag to ghc and add the package "markdown-unlit" to your dependencies. Additionally you have to symlink your .md file to .lhs, as ghc does not look at .md files (even with the --markdown-unlit flag, which I find kinda sad)

Re: Corrode: C to Rust translator written in Haskell

#100
post #91
post #88

Earlier quoted context omitted.

When it comes to connotations, the one's associated with Rust are beyond negligible...

How so? For me, "rust" conjures images of a rusty nail, rust getting in your tap water, a machine in disrepair from rust, and becoming "rusty" at some skill. And I don't think I'm alone.

And Python conjures images of dangerous snakes (and people getting killed by them), Go conjures images of that argument with my SO, when she told me "go!", C# conjures images of sharp objects like knives, and PHP conjures images of programming in PHP.

It's just a name, nobody really cares about rusty nails and rust in tap water when discussing Rust the programming language. And by nobody I mean nobody in the statistical significant sense.

It's really bikeshedding.

Post reply on HN