Forgot your password?
Close
typodupeerror
Programming

Canonical is Funding a PhD to Automate C to Rust Translation (itsfoss.com) 65

Posted by EditorDavid from the language-barriers dept.
An anonymous reader shared this report from the blog It's FOSS: Canonical has committed funding to a three-year PhD project focused on building a system that can automatically translate large C codebases into Rust. And they are not alone; UK Research and Innovation is matching their funding for the project, which is set to run through the University of Bristol's Programming Languages Research Group.

The PhD is aiming to build an all-encompassing platform that can take a C repository running into hundreds of thousands of lines and translate it into Rust that's "safe, behaviourally correct and maintainable Rust."

The work will be carried out by a student, Alex Wood, who will be supported by Professor Meng Wang leading the work, with Dr. Cristina David and Canonical's Jon Seager serving as co-supervisors.
This discussion has been archived. No new comments can be posted.

Canonical is Funding a PhD to Automate C to Rust Translation More

Canonical is Funding a PhD to Automate C to Rust Translation

Comments Filter:

  • How is that even possible? (Score:5, Insightful)

    by dskoll ( 99328 ) on Sunday August 23, 2026 @10:43AM (#66303154) Homepage

    If the C code does something unsafe, how can it be machine-translated into safe Rust, without knowing the intention of the programmer?

    And even is this is possible, what's the point? Why not just make a C compiler that emits "safe" assembler directly? It's not as if a transpiler is likely to emit human-maintainable code.

    I know Canonical is all hot for Rust, but this particular project doesn't seem feasible to me.

    • Re:How is that even possible? (Score:5, Insightful)

      by allo ( 1728082 ) on Sunday August 23, 2026 @11:41AM (#66303226)

      You're looking at the problem in a wrong way.
      C operations are unsafe and you need to implement safeguards yourself. Sometimes you can implement things rust can't because C allows you unsafe operations, but most programs only implement things that are possible in a safe way, but may fail to guard them (or have secure code that easily becomes insecure when some amateur tries to extend it).

      Think of working with a zero terminated string. These operations can easily be translated into every higher level programming language. In C you can easily make mistakes that lead to crashes or even security issues. A translation to e.g. rust (or other more reasonable languages) can translate both the correct implementation and slightly wrong implementations to a safe implementation.

      The point why you need a PhD instead of a motivated amateur is probably to automatically detect if the unsafe operation can be translated into the nearest safe operation of if the code really implements something that needs to deal with dangerous operations to implement features that are complicated or inefficient without them.

      • Re: (Score:2)

        by AmiMoJo ( 196126 )

        Hopefully they make significant gains when it comes to maintainability and readability as well. A lot of AI generated code looks superficially properly commented, decent variable names, that sort of thing, but in reality is a pain to deal with and only likely to ever be worked on again by more AI.

        • Re: (Score:3)

          by allo ( 1728082 )

          You may need to add something about the style of comments you want to your system prompt. AI defaults to a certain style of comments, which help to understand what a function does and where it related to, but also add "unneeded" documentation about decisions during the development process. I think much of it are signposts for later AI runs, which help AI to quickly understand the feature and where it related to without reading the full code base.

          That's also desirable for humans, but the human working with t

      • He's not looking at it the wrong way.

        You're essentially saying "But a technology that does this would be very valuable!"

        Yeah, no shit. So would a technology that turns lead into gold. Or that can tell whether some unwatermarked text is LLM generated or not.

        Like both of those cases, it's just not possible. C needs to be translated to Rust by someone who knows the intent of the programmer, as the GP pointed out. Most of the time that's not possible to automate. There are far too many edge cases.

        In C a string

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          You have some point here, except your exact example is exactly where an LLM can be perfectly fine for this.

          If you have a char array and you look through the rest of the program for uses of that array and they are all string operations then convert it to a string.
          If you have a char array and you see it selected from typecast to various different data structures then it was binary data

          The LLM can have the advantage of holding the whole related code in it's context window so it's able to do that decision immed

        • It is perfectly possible to turn lead into gold. The technology has been there for decades. It is simply not economical to do so.

        • Re: (Score:2)

          by allo ( 1728082 )

          They seem to plan to use AI for that, and AI can do that in many cases. I'd also think one idea could be to check the backward path. AI does C to rust and then you have some safe code and can verify if the corresponding safe C (strict bound checks, etc.) matches what the unsafe C did (or should have done) to double check the AI translation.

    • Re:How is that even possible? (Score:4, Interesting)

      by gweihir ( 88907 ) on Sunday August 23, 2026 @11:52AM (#66303236)

      It is not actually possible. Or rather unsafe stuff in C will remain unsafe in Rust. In addition, most/all other bugs (like logic errors, wrong use of system APIs, etc.) in the C code will remain. Rust does not magically make code secure. Coding directly in Rust has some advantages, as it is hard to learn and that keeps the prevalent low-skill coders out. Rust can also avoid some problems (not that many) when the code is designed for Rust. C code is obviously not.

      That said, there is an application scenario for this: If you C code is in good shape, but you want to do additional development and maintenance in Rust from a certain point onwards. That does not improve the old C/Rust code, but it may have some benefits for new code and for changes.

      • Re: (Score:2)

        by dskoll ( 99328 )

        If the resulting Rust code is human-readable and human-maintainable, then yes... I can see wanting to continue in Rust rather than C as a valid use-case.

        • So, nobody knows how to code in C anymore is the reason for wanting to transcode all C to Rust?

          • So, nobody knows how to code in C anymore is the reason for wanting to transcode all C to Rust?

            Not even "nobody" but for some people "a falling number with visibly increasing consulting rates" would be enough.

            • Coding in C is not complicated.

              So, nobody knows how to code in C anymore This is a stupid sentence. Perhaps by one who never programmed anything.

              However why would anyone use a low level language if he can use a high level one, which makes him more productive, and potentially reduces defect rates?

              Imagine writing an App for a smartphone in C, when you can use Swift, Dart or Java (and its derivates like Kotlin): that would not make any sense at all.

              • I agree that for those of us who come into the field before Java, C is about as simple as it gets; there's literally not much to know about the language. However, the majority of post-Java programmers have no idea what a pointer is or the first thing about manual memory management. I actually prefer to work in C over Swift, and luckily Swift bridges to C quite nicely. I use C and Zig for much of my server work, and for smartphone and desktop apps under the UI. Why? Because I get fine-grained control over me

                • Well,
                  nitpicking: everything in Java is a pointer :P
                  We just call it reference.
                  However Java has no pointer arithmetic, so you have a point about pointers.

                  and more memory-efficient than comparable apps
                  Unlikely.

          • Re:How is that even possible? (Score:5, Funny)

            by gweihir ( 88907 ) on Monday August 24, 2026 @05:34AM (#66304166)

            That is not the point. The point is that new code gets the minor security benefits of Rust and the major benefits that all the mediocre and bad coders will be unable to learn Rust. Hence when you hire for a Rust job, you get a much better selection of candidates.

        • Re: (Score:2)

          by gweihir ( 88907 )

          Yes. I would see readability and maintainability as the primary research focus of this PhD. Basic C-to-Rust translation has already been done and is not actually hard to do. It just does not get you much.

    • It will be crusty for sure

    • Re:How is that even possible? (Score:5, Insightful)

      by Mr. Barky ( 152560 ) on Sunday August 23, 2026 @01:44PM (#66303398)

      My bet is that 99% of C code is easily translatable and doesn't need to do anything unsafe (it may use unsafe methods, but basically in a safe way). If an automatic translator could do that 99% of code and flag the 1% that it cannot handle, that would still be a major time saver in translating it to Rust. This may be a reasonable goal rather than aiming at 100%.

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      If the C code does something unsafe, how can it be machine-translated into safe Rust, without knowing the intention of the programmer?

      The key word being "if".

      There's a ton of C code out there, the vast majority of which doesn't do anything unsafe. Take say, Apache httpd - what unsafe thing would it do? It just forks, spits a file out over a socket and that's it. The most unsafe thing it does would be to run a plugin, but that's mostly handled by the dynamic loader.

      In fact, most userspace code out there isn

      • This is so wrong. I speak from experience working on many httpd and libraries written in C/C++/assembly. There is a ton that can gp wrong. A lot has to do with input validation and undefined behavior. These problems can lead to crashes and remote code execution vulnerabilities. I'm not a Rust advocate. I still code in C/C++. But this is reality.

    • Easy - it will just spray the unsafe keyword all over the place.

    • If the C code does something unsafe, how can it be machine-translated into safe Rust, without knowing the intention of the programmer?

      You clearly don't understand what's going on here. Rust is magic. Rust makes the grass grow and the birds sing and the sun shine. Translating C to Rust applies the magic to that as well, so it'll also magically turn bad code into good code.

      Of course if they were really serious about this then they'd translate it into Haskell, because it's impossible to write buggy code in that, or so an academic once told me.

    • If the C code does something unsafe, how can it be machine-translated into safe Rust, without knowing the intention of the programmer?
      I would assume that is what the PhD is about: figuring that out.

    • The project is "C into Rust" not "C into safe Rust". Rust allows `unsafe { ... }`.

  • don't get it (Score:3)

    by fluffernutter ( 1411889 ) on Sunday August 23, 2026 @10:44AM (#66303158)
    Why not just use the time to make a safe c library of operations and use it?

    • Re: (Score:3, Interesting)

      by haruchai ( 17472 )

      Why not just use the time to make a safe c library of operations and use it?

      make sense to me but almost 20 years after someone began the Safe C library it's still a work in progress?
      https://jacobfilipp.com/DrDobb... [jacobfilipp.com]

      • That's general purpose. The company could write it to be specific to them. Don't have a hundred different inventions of an array from a pointer with a counter, write one and test it and use it everywhere.

    • Re: (Score:3)

      by unrtst ( 777550 )

      Why not just use the time to make a safe c library of operations and use it?

      Is this not one way of doing it? And it's a way that will ensure future code contributions are much less likely to introduce stupid bugs (assuming you agree that Rust does just that).

      I don't understand all the naysayers claiming it can't be done. Of course it can be done!

      Weird stuff in the code (example above was a char array used to hold binary data) can be examined for how its used to deduce the correct implementation - one of the things that LLM's are actually good at. And since it's talking about large

  • Oh, now I get it. (Score:3)

    by packrat0x ( 798359 ) on Sunday August 23, 2026 @11:05AM (#66303182)

    Rust Performance vs C Performance [rustfaq.org]
    Memory Management in Embedded Systems: A Comparative Analysis of C and Rust [parvezshaik.info]

    You use Rust's safety features while writing / debugging, but
    turn off Rust's safety features (cargo run --release), when you're done.
    That way you don't get abysmal performance from performing safety checks.

    Although, couldn't this be done in C as well?

    • turn off Rust's safety features (cargo run --release), when you're done.

      That's like removing your seat belts after the vehicle crash tests are done.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Although, couldn't this be done in C as well?

      It can be. But it requires high coders skills and insights. In Rust the skill requirements are probably a bit (not that much) lower, but since Rust is hard to learn, you force competence in an indirect way. Yes, stupid, but that is one of the hoops needed to convince clueless "management".

    • Re: Oh, now I get it. (Score:5, Insightful)

      by reg ( 5428 ) <reg@freebsd.org> on Sunday August 23, 2026 @11:58AM (#66303254) Homepage
      Because the point of Rust is that it's safe by design. In other words, once you've figured out how to structure your program to make it not do unsafe things, you have a design you can just implement in C and (as long as it's a faithful implementation), and it will also be guaranteed to be safe. The only reason not to is that maintenance is harder that way. It also shows that Rust has to many limits because code that is provably safe by a human cannot be written in Rust without a redesign to meet Rust's more limited understanding of safe.

  • Weâ(TM)re already doing this (Score:4, Informative)

    by daveschroeder ( 516195 ) * on Sunday August 23, 2026 @11:09AM (#66303194)

    https://www.cs.wisc.edu/2025/0... [wisc.edu]

    And DARPA has a whole program for it:

    https://www.darpa.mil/research... [darpa.mil]

  • They see me vibe codin', they hatin', tryin' to catch me debuggin' dirty. Tryin' to catch me debuggin' dirty. Tryin' to catch me debuggin' dirty. Tryin' to catch me debuggin' dirty. My IDE is open, my terminal is glowing, and my Spotify playlist is riding heavy. Think I'm just copy-pasting Caude Code, but I'm a fully funded PhD candidate.

  • It's not the language it's the management (Score:4, Interesting)

    by FeelGood314 ( 2516288 ) on Sunday August 23, 2026 @11:17AM (#66303202)
    The C code at most large companies I've worked at has been total crap. My high school CS teacher probably wouldn't have accepted the code from my last company even to mark it since it lacked descriptions of the projects and comments. This isn't something that can be fixed with a new language. C at least won't compile if someone is an idiot so usually about 25% of the C devs are worth the air they breath which is far better than the JavaScript devs. The issue is managers wanting steady, easy to measure progress but not wanting to invest any time in understanding the project. Concurrency issues are solved by architecting the code correctly but if you only measure progress by how fast a jira ticket is solved by an engineer who has been on the project for 2 hours then you get people manipulation buffers in interrupts as well as in the single thread of the application. If there are no comments about what a buffer is then yes, pointers to it will be miss used. C code runs fast, has a small image size, I can bash memory directly, that's the point. If you don't plan your code, if the logic is never written out then it doesn't matter what the language is, your code will do the wrong thing. Memory bugs are just easier to find but making the language convoluted to stop stupidity just makes it harder to find stupid programmers and even harder to find incorrect logic. Rust is bad coders solving the wrong problems. If, as a manager, your devs can't simplify the architecture enough to explain how the code will meet the functional requirements then either the devs suck or you shouldn't be a manager..... and if you don't have a clear functional requirement, even if you know it will change next week, then you as a manager aren't doing your job.

    • Re: (Score:2)

      by gweihir ( 88907 )

      The problem with C is that it is easy to learn, but hard to master. The primary advantage of Rust is that it is hard to learn and hard to master. That keeps the idiots out and it probably its most significant actual security advantage.

      • Some parts of C are easy to learn but pointers, particularly double and beyond , plus pointers vs arrays, tends to trip up the no hopers.

        • Some parts of C are easy to learn but pointers, particularly double and beyond , plus pointers vs arrays, tends to trip up the no hopers.

          They'll have the same problem with Rust, which also uses pointers all over the place (though it calls them references). The difference is that the no hopers will be unable to get the Rust code to compile, while with C they can get it to build... and then hope that valgrind can find the ways it's broken -- because it is broken. They might be able to get the Rust to compile by eschewing pointers and cloning every damned thing so the borrow checker will shut up, making their code so inefficient that they mig

          • you can get this behavior in C if you tag your pointers with strict

            I meant restrict, of course.

  • I see most comments are assuming this is done with AI but this isnâ(TM)t necessary. It would make more sense to compile C to the intermediate code, then generate rust that would generate the same intermediate codes. As for unsafe rust it would be a huge win to translate all the regular C to rust, and only have some sections that need unsafe rust, vs the entire code base being essentially unsafe. An upshot of conversion might be the automatic converter canâ(TM)t find a safe equivalent for some c co
  • In other words, they are throwing their money to influence an open source project.
  • Translating garbage code creates even worse garbage code. I remember years ago a company I was with hired a company to translate COBOL to Java.

    It was still crap when it was all over and the project was flushed. The biggest sin was the naming conventions used by the original code were maintained.

    I've migrated code from one language to the other, and the best end results I've achieved were when I reverse engineered the original code and wrote the new code from scratch. It took longer, but in the proc

    • I loved it when the QA people would come back to me and say the results weren't the same, only to discover the original program had an undiscovered error.

      To me, that implies the QA people were running a new test that had not been run on the original code. If it had been run on the original code, they would have produced the same results.

      The question to ALWAYS ask the QA people in this circumstance is, "what was the result when you previously ran this test on the prior product?" This question could ha

  • Translating code from one language to another is not that hard. Getting code that was translated that can be easily maintained is difficult.
  • We will also need to convert maintainers to Rust. I suspect it is better to have maintained code in C, rather than abandonware in Rust.
  • It seems the blinkers are on and all they can see is Rust...
  • An assembly language to Rust converter would enable any language to be converted, even rust to rust

Slashdot Top Deals

He who is content with his lot probably has a lot.

Close