It doesn't provide any additional safety by itself, but it does provide a good starting point. Once you've Corroded your existing C code, you can then replace the unsafe Rust abstractions (like raw pointers) with equivalent safe ones (like references), one at a time. This way the manual part of the conversion doesn't have to be done all at once.

Is there anything that prevents this conversion of raw pointers to references from being automatable as well?

Rice's theorem.

That's an overly glib answer. The fully general form of this problem is undecidable, but it would be theoretically possible to build a "reverse borrow checker" that analyzes a Rust program, detects raw pointers that are provably used exclusively in ways compatible with Rust's lifetime semantics, and converts them to references. But it would probably be a fairly major project requiring lots of specialized knowledge, because lifetime semantics are complicated. Nobody has attempted it yet as far as I know, although the author of Corrode has expressed interest.

If C was able to encode Rust's semantics around references, you wouldn't need Rust in the first place.

You might be able to get it to work sometimes for a very simple subset. I'd be extremely skeptical that it'd be very useful, though.

I agree with "sometimes, for a very simple subset" but I think there's a good chance that can still be very useful. A lot of uses just are super simple, and that may be obvious to the computer in cases that aren't obvious to the human. If we can remove the need for the human to reason about those, that can be a big help.

Yeah I mean, compilers don't fix bugs. I don't know what you want. This is taking the "sufficiently smart compiler" idea to absurdity.

As part of an incremental re-write or port, this is still useful. It is extremely close to being able to straight-up cross compile CVS, for example.

Yeah, I suppose the larger challenge is how to convert unsafe C to safe Rust.

Most of the problems revolve around "how big is it". (The three big problems in C are "how big is it", "who owns it", and "who locks it". C has no language constructs for any of those, while Rust does.)

If a C program works at all, there has to be some computable expression for the length of a C array. Code that uses an array passed as a pointer has to know how big the array is, even though C lacks a language construct for this. The problem is finding that expression. For many cases, it can be automatically inferred, especially if you have cross-module analysis and can see where the original array came from.

I once proposed an extension to C to allow expressing array size information.[1] Discussions indicated it was technically sound but politically too much trouble. It gives a hint, though, of how to approach size information in C. Instead of

    int read(int fd, char buf[], size_t len);

one would write

    int read(int fd, char& buf[len], size_t len); 

Same generated code for the call, but now the source code contains size information, which could be used for subscript checking by the caller and callee. A serious C to Rust converter needs to be able to detect relationships like that.

It doesn't have to be 100% automatic. If the converter could knock off most of the easy cases (especially those involving strings), and accept hints on the hard ones, it could be usable.

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