I think we have to take that literally: They only translate C code to Rust. Not C++.
Translating All C to Rust (TRACTOR)
111–120 of 403 posts
Re: Translating All C to Rust (TRACTOR)
#112It's good to see DARPA pushing on this. It's a hard problem, but by no means impossible. Translating to safe Rust, though, is going to be really tough. There's a C to Rust translator now, but what comes out is horrible Rust, which just rewrites C pointer manipulation as unsafe Rust struct manipulation. The result is less maintainable than the original. So what would it take to actually do this right? The two big prob…
I once tried to use c2rust as a starting point for rustification of code and... it's not even good at that. The code is just too freakishly literal to the original C semantics that you can't even take the non-pointery bits and strip off the unsafe block and use that as a basis.
(To give you a sense, it translates something like a + 1 to a.unwrapped_add(1i32), and my recollection is that for (int i = 0; i In general, the various challenges that all need to be solved that aren't solved yet are:
a) when is integer overflow intentional in the original code so that you know when to use wrapping_op instead of regular Rust operators?
b) how to convert unions into Rust enums
c) when pointers are slices, and what corresponds to the length of the slice
d) convert pointers to references, and know when they're mutable or const references
e) work out lifetime annotations where necessary
f) know when to add interior mutability to structs
g) wrap things in Mutex/RwLock/etc. for multithreaded access
We're a very long way from having full-application conversion workable, and that might be sufficiently difficult that it's impossible.
Re: Translating All C to Rust (TRACTOR)
#113Earlier quoted context omitted.
> There are good reasons to favor Rust's flavor of UB over C++'s, but I keep seeing these same incorrect arguments getting repeated everywhere, which is frustrating. Tell me what I wrote that was incorrect. I called them UB bugs in the standard library. If they were trivial bugs that caused some defined-behavior logic bug while used outside of the standard library then it wouldn’t rise to the level of being called an…
> They are not UB-as-a-feature like in C/C++. That's the part that's incorrect. That, plus the implication that UB is a bug in Rust, but not in C++. As I said, the existence of UB is a feature in both languages and actually encountering UB is a bug in both languages. You can play with the semantics of the word "feature" but I don't think it's possible to find a definition that captures C++ UB and excludes Rust UB wit…
You’re done editing the comment now?
Do you think UB-as-feature is something that someone would honestly describe C or C++ as? It’s a pretty demeaning way of framing things. Indeed it’s a tongue-in-cheek remark, a vhimsical exaggeration/description of the by-default UB of those languages which was added to the end of the completely factual description of the role that finding UB in the Safe Rust subset of the standard library of Rust serves.
Of course one cannot, from the Rust Side so to speak, use tongue in cheek, off-hand remarks in these discussions; one must painstakingly add footnotes and caveats, list and mention every trivial fact like “you can get UB in unsafe blocks”[1] or else you have a “double standard”.
[1] Obligatory footnote: even though all participants in the discussion clearly knows this already.
Re: Translating All C to Rust (TRACTOR)
#114This isn't some "pie in the sky" thing, Immunant has a working C to Rust transpiler and it's really interesting: https://github.com/immunant/c2rust
As I mentioned elsewhere (https://news.ycombinator.com/item?id=41113257), that tool is pretty much useless unless you have some checkbox that says "no C code allowed anywhere". It's not even a feasible starting point for refactoring because the code is so far from idiomatic Rust.
Re: Translating All C to Rust (TRACTOR)
#115Earlier quoted context omitted.
There are some soundness holes in the implementation that can cause this. Just like any project, the compiler can have bugs. They’ll be fixed just like any bug.
Ah, a voice of sort-of sanity, at long last. So, the reason I posted my original reply, is that at one of my $DAYJOBs, we recently had a 3-day outage on some service, related to Rust. Something like using AVX to read, like, up to 7 bytes too many from an array. Nothing really major -- we have a 10-day backup window, and the damage was limited to 4 days, so we were able to identify and fix all identified cases. But th…
[deleted]
Re: Translating All C to Rust (TRACTOR)
#116Earlier quoted context omitted.
There are some soundness holes in the implementation that can cause this. Just like any project, the compiler can have bugs. They’ll be fixed just like any bug.
Ah, a voice of sort-of sanity, at long last. So, the reason I posted my original reply, is that at one of my $DAYJOBs, we recently had a 3-day outage on some service, related to Rust. Something like using AVX to read, like, up to 7 bytes too many from an array. Nothing really major -- we have a 10-day backup window, and the damage was limited to 4 days, so we were able to identify and fix all identified cases. But th…
> I'm just a C# wagie, and I fully accept that my code, my language, my compiler, and my runtime environment are all shit.
What is shit about those things for C#? That’s the application programming language that seems to get the least flak out of all of them.
If I’m using an alpha or beta compiler, I might suspect a compiler bug from time to time… not really when I’m working in a decades-old, very established language.
Re: Translating All C to Rust (TRACTOR)
#117I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…
If you have dormant code, as in running everywhere but not getting worked on anywhere, a "translate to shitty rust before ever touching again" has a certain appeal. Not the appeal of an obviously good idea: chances are the "shitty rust" created through translation would be so much worse to work on than C with some level of background noise of bugs (that would also be present in the "shitty rust" thanks to faithful translation). In C, people have an idea about how to deal with the problems. In "shitty rust", it's, well, shitty, because rust people are not used to that stuff.
But there's a non-zero chance that someone could develop a skillset for iteratively cleaning up into something tolerable.
And then there are non-goal things that could grow out of the project, e.g. some form of linter feedback "can't translate into tolerable rust because of x, y and z". C people could look into that, and once the code is translatable into good rust, why translate.
If that was an outcome of the project, some people might find it easier to describe their solution in runnable C and let the "translator/linter" guide them to a non-broken approach.
I'd certainly consider all these positive outcomes quite unlikely, but isn't it pretty much the job description of DARPA to do the occasional dark horse bet?
Re: Translating All C to Rust (TRACTOR)
#118Earlier quoted context omitted.
> Well, the general 'Rewrite All in Rust' consensus is that it solves all general programming problems, ever. This is obvious example of strawman. Why are you doing this?
Towards general mental health. I'm just a C# wage slave, and I'll admit, when being prompted, that my language, its vendor, its runtime environment, and its general approach are, to put it kindly, flawed . However, as evidenced by the arguments and voting in this thread, Rust proponents will take no criticism, whatsoever . I linked to a GitHub repository that documents many, many instances in which generally safe Rus…
Stoking language flame wars based on hysterical exaggeration has never promoted mental health.
Re: Translating All C to Rust (TRACTOR)
#119Earlier quoted context omitted.
Yes, it is a core design tenet of the language. It's as benign a statement as "C# has garbage collection." That's not "reluctant to offer compromise."
OK, you truly seem not to understand how much damage you're dealing to the general population using absolutist statements like this, do you? Nor do you seem to understand "compromise", like at all , because you seem to equate it with "tit for that", which is unsurprising, but still... disappointing. In any case, I'm truly done here, in all senses of the word, but I still I wish you and your acolytes the absolute best…
Calling Steve Klabnik (of all Core Rust background people, literally all of them) an “absolutist” proves how unreasonable you’re being.
Re: Translating All C to Rust (TRACTOR)
#120That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…
I have to imagine that in the general case it will be a translation to unsafe Rust, with occasional isolated leaf nodes being translated to safe Rust.
If you think it's hard wrestling with the borrow checker, just imagine how much harder it is to write automatic translation to borrow-checker-approved code that accounts for all the possible program space of C and all it's celebrated undefined behavior. A classic problem of writing compilers is that the space of valid programs is much larger than the space of programs which will compile.
A quick web search reveals some other efforts, such as c2rust [1]. I wonder how TRACTOR differs.