HN2new | past | comments | ask | show | jobs | submitlogin

How does this compare to Corrode? The trouble with these things is that the Rust that comes out is usually too awful to maintain. Corrode, too, said that someday they'd generate more reasonable Rust. But that never happened. Converting C into Rust with unsafe raw pointers is not all that useful.

What's needed is some way to provide key information C doesn't have. Mostly about array sizes. Some way to annotate

   int read(int fd, void* buf, size_t len)
to tell the system that buf has size len.

A file of translation hints with such info could guide the translator into producing decent Rust. Most of the things done with pointer arithmetic can be expressed with slices. (Things being done with pointer arithmetic which can't be expressed as slices should be viewed with deep suspicion.) But you need size info to do that.



The short form is that Corrode is effectively deprecated in favor of c2rust. Indeed, Corrode hasn't been updated since 2017, while c2rust still gets active development—last commit as of my writing this was 2 days ago.

It's worth noting that the developer of Corrode was consulted on the early design of c2rust, which means c2rust was able to benefit from hindsight on architectural decisions in Corrode. That ended up leading to a bit of a messy history between the two (c.f. https://jamey.thesharps.us/2018/06/30/c2rust-vs-corrode/ with HN discussion https://hackertimes.com/item?id=17436371 —although I believe that after that blog post the c2rust developers did end up acknowledging their inspiration and apologized for not doing so earlier.)


The goal of C2rust is not to produce good maintainable Rust.

It’s to produce buildable rust which exactly matches the original code, which you can then migrate to proper rust.

So your query is really in the “not even wrong” category.


which you can then migrate to proper rust.

Which means you have to manually work on that awful code that comes out. In the chart at [1], this step is represented by a magic wand.

(I wanted to give some examples, but https://c2rust.com/ seems to not be translating today.)

[1] https://c2rust.com/manual/


> What's needed is some way to provide key information C doesn't have. Mostly about array sizes.

You also want to know which way the data flows (i.e. is buf read from, written to, or both). And then you end up with something like this:

https://learn.microsoft.com/en-us/cpp/code-quality/understan...


I proposed an extension to C which adds slices:

https://www.digitalmars.com/articles/C-biggest-mistake.html


Me too.[1]

But it would have meant years of work on language politics.

It might be worth looking at this sort of thing again, because machine learning is far enough along that recognizing and converting the usual array idioms is feasible. If the output code with array bounds is run time checked, then errors in translation will result in detected array bounds errors.

[1] http://animats.com/papers/languages/safearraysforc43.pdf


Yes, Windows has been doing that with SAL annotations for years.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: