Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiling C to Safe Rust, Formalized

arxiv.org

Post reply on HN
Print view View original

131–140 of 173 posts

Re: Compiling C to Safe Rust, Formalized

#131

Post by colejohnson66 »

LPisGood wrote: post #128
pizza234 wrote: post #126

I've ported some projects to Rust (including C, where I've used C2Rust as first step), and I've drawn some conclusions. 1. Converting a C program to Rust, even if it includes unsafe code, often uncovers bugs quickly thanks to Rust’s stringent constraints (bounds checking, strict signatures, etc.). 2. automated C to Rust conversion is IMO something that will never be solved entirely, because the design of C program is…

>because unsafety can be inherent in the design I agree in principle, and I have strong feelings based on my experience that this is the case, but I think it would be illustrative to have some hard examples in mind. Does anyone know any simple cases to ground this discussion in?

Maybe a JIT? Especially one that can poke back into the runtime (like dotnet).

Re: Compiling C to Safe Rust, Formalized

#132

Post by LPisGood »

colejohnson66 wrote: post #131
LPisGood wrote: post #128

Earlier quoted context omitted.

>because unsafety can be inherent in the design I agree in principle, and I have strong feelings based on my experience that this is the case, but I think it would be illustrative to have some hard examples in mind. Does anyone know any simple cases to ground this discussion in?

Maybe a JIT? Especially one that can poke back into the runtime (like dotnet).

I know Unity game engine uses some transpiler called IL2CPP that manages to preserve some of the safety features of C# but still gets the speed of CPP, so one direction is definitely possible

Re: Compiling C to Safe Rust, Formalized

#133

Post by tatref »

nuancebydefault wrote: post #130
LPisGood wrote: post #128

Earlier quoted context omitted.

>because unsafety can be inherent in the design I agree in principle, and I have strong feelings based on my experience that this is the case, but I think it would be illustrative to have some hard examples in mind. Does anyone know any simple cases to ground this discussion in?

Suppose it is a dll that has exported functions returning or accepting unsafe strings. No way to make it safe without changing the API.

In Rust, there is no unsafe String, only blocks of code can be unsafe, no?

Re: Compiling C to Safe Rust, Formalized

#134

Post by medo-bear »

keybored wrote: post #125
medo-bear wrote: post #115

Earlier quoted context omitted.

The point, I think, was that "safety" presumptions about Rust are often exaggerated or poorly misunderstood due to hype. That could certainly lead to problems

> The point, I think, was that "safety" presumptions about Rust are often exaggerated or poorly misunderstood due to hype. That could certainly lead to problems Then the point is hypocritical. Runtimes for safe programming languages have been implemented in unsafe languages since the dawn of safe programming languages, basically. EDIT: I see now that you are the cigarette warning guy. In that case I don’t understand…

Your tendency to answer jokes so seriously is a symptom of the hype

Re: Compiling C to Safe Rust, Formalized

#135

Post by whytevuhuni »

tatref wrote: post #133
nuancebydefault wrote: post #130

Earlier quoted context omitted.

Suppose it is a dll that has exported functions returning or accepting unsafe strings. No way to make it safe without changing the API.

In Rust, there is no unsafe String, only blocks of code can be unsafe, no?

They likely mean a char* pointer to a null-terminated string, or a char* pointer and a length, as is usual for C.

If Rust was forced to expose such an API (to be on par with C's old API), it would have to use `*const u8` in its signature. Converting that to something that can be used in Rust is unsafe.

Even once converted to &[u8], it now has to deal with non-UTF8 inputs throughout its whole codebase, which is a lot more inconvenient. A lot of methods, like .split_ascii_whitespace, are missing on &[u8]. A lot of libraries won't take anything but a &str.

Or they might be tempted to convert such an input to a String, in which case the semantics will differ (it will now panic on non-UTF8 inputs).

Re: Compiling C to Safe Rust, Formalized

#136

Post by int_19h »

pizza234 wrote: post #126

I've ported some projects to Rust (including C, where I've used C2Rust as first step), and I've drawn some conclusions. 1. Converting a C program to Rust, even if it includes unsafe code, often uncovers bugs quickly thanks to Rust’s stringent constraints (bounds checking, strict signatures, etc.). 2. automated C to Rust conversion is IMO something that will never be solved entirely, because the design of C program is…

> automated C to Rust conversion is IMO something that will never be solved entirely

Automated conversion of C to safe fast Rust is hard. Automated conversion of C to safe Rust in general is much easier - you just need to represent memory as an array, and treat pointers as indices into said array. Now you can do everything C can do - unchecked pointer arithmetic, unions etc - without having to fight the borrow checker. Semantics fully preserved. Similar techniques have been used for C-to-Java for a long time now.

Of course, the value of such a conversion is kinda dubious. You basically end up with something like C compiled to wasm, but even slower, and while the resulting code is technically "safe", it is still susceptible to issues buffer overflows producing invalid state, dangling pointers allowing access to data in contexts where it shouldn't be allowed etc.

Re: Compiling C to Safe Rust, Formalized

#137

Post by Rusky »

pizlonator wrote: post #19
pornel wrote: post #17

Earlier quoted context omitted.

Rust's ownership model is close enough for translating C. It's just more explicit and strongly typed, so the translation needs to figure out what a more free-form C code is trying to do, and map that to Rust's idioms. For example, C's buffers obviously have lengths, but in C the length isn't explicitly tied to a pointer, so the translator has to deduce how the C program tracks the length to convert that into a slice.…

Rust’s ownership model forbids things like doubly linked lists, which C programs use a lot. That’s just one example of how C code is nowhere near meeting Rust’s requirements. There are lots of others.

Rust's ownership model has two aspects:

- A dynamic part specifies what is actually allowed, and totally supports doubly linked lists and other sorts of cyclic mutable data structures.

- A static part conservatively approximates the dynamic part, but is still flexible enough to express the interfaces and usage of these data structures even if it can't check their implementations.

This is the important difference over traditional static analysis of C. It enables `unsafe` library code to bridge the dynamic and static rules in a modular way, so that that extensions to the static rules can be composed safely, downstream of their implementation.

Rust's strategy was never for the built-in types like `&mut T`/`&T` to be a complete final answer to safety. It actually started with a lot more built-in tools to support these patterns, and slowly moved them out of the compiler and runtime and into library code, as it turned out their APIs could still be expressed safely with a smaller core.

Something like Fil-C would be totally complementary to this approach- not only could the dynamic checking give you stronger guarantees about the extensions to the static rules, but the static checks could give the compiler more leverage to elide the dynamic checks.

Re: Compiling C to Safe Rust, Formalized

#138

Post by keybored »

medo-bear wrote: post #134
keybored wrote: post #125

Earlier quoted context omitted.

> The point, I think, was that "safety" presumptions about Rust are often exaggerated or poorly misunderstood due to hype. That could certainly lead to problems Then the point is hypocritical. Runtimes for safe programming languages have been implemented in unsafe languages since the dawn of safe programming languages, basically. EDIT: I see now that you are the cigarette warning guy. In that case I don’t understand…

Your tendency to answer jokes so seriously is a symptom of the hype

Me being humorless (read: not just rolling with your cop-out) is a symptom of the Rust hype.

Doesn’t even make sense.

Re: Compiling C to Safe Rust, Formalized

#139

Post by zozbot234 »

int_19h wrote: post #136
pizza234 wrote: post #126

I've ported some projects to Rust (including C, where I've used C2Rust as first step), and I've drawn some conclusions. 1. Converting a C program to Rust, even if it includes unsafe code, often uncovers bugs quickly thanks to Rust’s stringent constraints (bounds checking, strict signatures, etc.). 2. automated C to Rust conversion is IMO something that will never be solved entirely, because the design of C program is…

> automated C to Rust conversion is IMO something that will never be solved entirely Automated conversion of C to safe fast Rust is hard. Automated conversion of C to safe Rust in general is much easier - you just need to represent memory as an array, and treat pointers as indices into said array. Now you can do everything C can do - unchecked pointer arithmetic, unions etc - without having to fight the borrow checke…

You can do a lot better than that. You can treat memory ranges coming from separate allocations as distinct segments, and pointers as tuples of a segment ID and a linear offset within the segment. This is essentially what systems like CHERI are built on, and how C and C++ are implemented on segmented architectures like the 8086 and 80286. The C standard includes a somewhat limited notion of "objects" that's intended to support this exact case.

Re: Compiling C to Safe Rust, Formalized

#140

Post by jeltz »

medo-bear wrote: post #134
keybored wrote: post #125

Earlier quoted context omitted.

> The point, I think, was that "safety" presumptions about Rust are often exaggerated or poorly misunderstood due to hype. That could certainly lead to problems Then the point is hypocritical. Runtimes for safe programming languages have been implemented in unsafe languages since the dawn of safe programming languages, basically. EDIT: I see now that you are the cigarette warning guy. In that case I don’t understand…

Your tendency to answer jokes so seriously is a symptom of the hype

Your irrational hate for a programming language adds nothing to the discussion.
Post reply on HN