How to not rewrite it in Rust • Hacker News Board

Re: How to not rewrite it in Rust

#171

Post by pjmlp » Wed, Oct 23, 2019, 9:59 PM UTC

The_rationalist wrote: post #154

pjmlp wrote: post #133

Earlier quoted context omitted.

Yep. C++/CLI, C++/CX, GC pluggable API introduced in C++11, C++ Builder VCL in ARC mode, Unreal C++ managed classes.

Do you know how much c++/cli is automatically compatible with c# code? And how much does it retain compatibility with standard c++?

Everything that obeys to CLS.

https://docs.microsoft.com/en-us/dotnet/standard/language-in...

https://docs.microsoft.com/en-us/cpp/dotnet/managed-types-cp...

Then you can also use regular low level stuff, but in that case you will get mixed mode Assemblies (other forms are now deprecated).

https://docs.microsoft.com/en-us/cpp/dotnet/mixed-native-and...

C++/CLI is basically a set of language extensions, just like clang and gcc have theirs.

Right now it supports up to C++14, if I am not mistaken.

Many don't seem to realise that CLR started as the next evolution of COM, with the required machinery to support VB, C#, J# and C++, alongside any other language that could fit the same kind of semantics.

Re: How to not rewrite it in Rust

#172

Post by pron » Wed, Oct 23, 2019, 10:04 PM UTC

erik_seaberg wrote: post #164

pron wrote: post #115

Earlier quoted context omitted.

> But the biggest reason to rewrite it in Rust is safety. This is not a good reason if there are cheaper ways to get safety (at least for existing codebases). Indeed, there are sound static analysis tools (like TrustInSoft) that guarantee no undefined behaviour in C code. Using them is not completely free, and it may even require adding annotations to the code or even changing the code, but it does seem significantly…

In practice, how much does “not completely free” cost? TrustInSoft doesn’t even publish prices, which pretty strongly suggests I couldn’t afford it nor persuade a manager to expense it.

The main cost either way is not licensing but effort.

Re: How to not rewrite it in Rust

#173

Post by pron » Wed, Oct 23, 2019, 10:05 PM UTC

kragen wrote: post #158

pron wrote: post #115

Earlier quoted context omitted.

> But the biggest reason to rewrite it in Rust is safety. This is not a good reason if there are cheaper ways to get safety (at least for existing codebases). Indeed, there are sound static analysis tools (like TrustInSoft) that guarantee no undefined behaviour in C code. Using them is not completely free, and it may even require adding annotations to the code or even changing the code, but it does seem significantly…

Undefined behavior is not the only kind of bug in C programs, and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it. Consider that one of the worst security bugs in history was a result of Kurt Roeckx eliminating an undefined-behavior bug from OpenSSL.

It's pretty much the only kind of bugs that Rust can prevent, too.

> and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it

It's pretty clear to me.

> Consider that one of the worst security bugs in history

I'm not sure what bug you're referring to, but if it's Heartbleed, than that was an undefined behavior bug. Of course, a functional bug can be introduced at any time, including during a rewrite in another language.

Re: How to not rewrite it in Rust

#174

Post by svat » Wed, Oct 23, 2019, 10:10 PM UTC

xvilka wrote: post #113

There is an automated tool - c2rust[1], automating a huge chunk of the translation from C to Rust. Moreover, it has a refactoring tool[2] that is scriptable in Lua. One of the good examples of such conversion (still not finished though), while still producing the same output is a rewrite[3][4] of XeTeX engine to Rust (as part of Tectonic[5] engine). It is able to parse arXiv articles dump and generate valid PDFs stil…

I wrote a comparison of the quality of this autogenerated C2rust code versus the original sources (WEB code in this case), the last time this was posted: https://news.ycombinator.com/item?id=21176806 (Though it's not a fair comparison as this particular automatic translation itself started from automatically translated C code, for unclear reasons.)

Re: How to not rewrite it in Rust

#175

Post by kragen » Wed, Oct 23, 2019, 10:11 PM UTC

pron wrote: post #173

kragen wrote: post #158

Earlier quoted context omitted.

Undefined behavior is not the only kind of bug in C programs, and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it. Consider that one of the worst security bugs in history was a result of Kurt Roeckx eliminating an undefined-behavior bug from OpenSSL.

It's pretty much the only kind of bugs that Rust can prevent, too. > and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it It's pretty clear to me. > Consider that one of the worst security bugs in history I'm not sure what bug you're referring to, but if it's Heartbleed, than that was an undefined behavior bug. Of course,…

No, I'm talking about the Debian OpenSSL bug Luciano Bello discovered. It was a lot worse than Heartbleed. Kurt Roeckx didn't introduce Heartbleed, and Heartbleed wasn't introduced by removing undefined behavior, so there is no plausible reason for you to infer that I was talking about Heartbleed.

As for the cost of rewrites, there's a lot of evidence from software project metrics that the cost of modifying software can easily exceed the cost of rewriting it; see Glass's Facts and Fallacies of Software Engineering for details and references. Also, though, it should be intuitively apparent (though perhaps nonobvious) that this is a consequence of the undecidability of the Halting Problem and Rice's Theorem — it's impossible to tell what a given piece of software will do, which means that the cost of reproducing its existing behavior in well-understood code is unbounded.

Re: How to not rewrite it in Rust

#176

Post by kragen » Wed, Oct 23, 2019, 10:24 PM UTC

Where are you getting your CHM files? If you're getting them from untrusted sources — that is, people you wouldn't give your password to — you probably don't want to pass them to a buggy C library. That's just begging to get pwned! The only way this seems like a reasonable idea is if your CHM files are generated by your own software or by something like SafeDocs: https://www.darpa.mil/program/safe-documents

Wrapping your buggy C library in Rust isn't going to give you the kind of security against malicious data that a rewrite in Rust would give you.

Re: How to not rewrite it in Rust

#177

Post by makapuf » Wed, Oct 23, 2019, 10:35 PM UTC

pjmlp wrote: post #168

makapuf wrote: post #163

Earlier quoted context omitted.

Also, adress sanitizer but iiuc it's not advised to keep it in production code.

Android ships a subset of it enabled in production.

Interesting, I could not find any links do you have some ?

Re: How to not rewrite it in Rust

#178

Post by nickpsecurity » Wed, Oct 23, 2019, 10:39 PM UTC

pjmlp wrote: post #102

ncmncm wrote: post #80

Earlier quoted context omitted.

I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the ineffici…

You mean custom benchmarks like Midori powering Bing for Asian requests, the ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google Cloud sandboxes. Yep, really lying.

The pre-Cortana version of the speech service ran on Midori, too, with safer code:

https://www.reddit.com/r/programming/comments/3t50xg/more_in...

They admit it wasn't quite full-GC stuff. It was close to the C++. It did use the language safety and parallelism to its advantage on top of the Midori OS. They ended up improving performance over the original.

Still worth mentioning even if not fully-GC. I mean, they could've always used a real-time GC if that was important. There's already commercial and academic ones. For some reason, these projects never try to do that. I think even those developing GC'd systems might not know about RT designs.

Re: How to not rewrite it in Rust

#179

Post by pron » Wed, Oct 23, 2019, 10:44 PM UTC

kragen wrote: post #175

pron wrote: post #173

Earlier quoted context omitted.

It's pretty much the only kind of bugs that Rust can prevent, too. > and it's far from clear that fixing all the bugs, or even all the undefined behavior, in an existing C library will be less effort than rewriting it It's pretty clear to me. > Consider that one of the worst security bugs in history I'm not sure what bug you're referring to, but if it's Heartbleed, than that was an undefined behavior bug. Of course,…

No, I'm talking about the Debian OpenSSL bug Luciano Bello discovered. It was a lot worse than Heartbleed. Kurt Roeckx didn't introduce Heartbleed, and Heartbleed wasn't introduced by removing undefined behavior, so there is no plausible reason for you to infer that I was talking about Heartbleed. As for the cost of rewrites, there's a lot of evidence from software project metrics that the cost of modifying software…

> so there is no plausible reason for you to infer that I was talking about Heartbleed.

Except that Heartbleed is the only OpenSSL bug I've heard of :) Also, I don't know who Kurt Roeckx is.

> there's a lot of evidence from software project metrics that the cost of modifying software can easily exceed the cost of rewriting it

But we're not talking about arbitrary modification, but about, at worst, fixing undefined behavior, which requires only local modifications (or Rust wouldn't be able to prevent that either). As an ultimate reduction, you could choose to rewrite the software in C and still use sound static analysis to show lack of undefined behavior.

> which means that the cost of reproducing its existing behavior in well-understood code is unbounded.

Yes, but that still doesn't mean that a rewrite is cheaper. Also, while your conclusion is correct, your statement of Rice's theorem is inaccurate: it's impossible to always tell what ever piece of software would do. It's certainly possible to tell what some software would do, at least in some cases, or writing software would be impossible to begin with.

BTW, if you're interested in the theory of software correctness, you might be interested in this blog post of mine, that lists relevant results: https://pron.github.io/posts/correctness-and-complexity

Re: How to not rewrite it in Rust

#180

Post by xvilka » Wed, Oct 23, 2019, 10:58 PM UTC

svat wrote: post #174

xvilka wrote: post #113

There is an automated tool - c2rust[1], automating a huge chunk of the translation from C to Rust. Moreover, it has a refactoring tool[2] that is scriptable in Lua. One of the good examples of such conversion (still not finished though), while still producing the same output is a rewrite[3][4] of XeTeX engine to Rust (as part of Tectonic[5] engine). It is able to parse arXiv articles dump and generate valid PDFs stil…

I wrote a comparison of the quality of this autogenerated C2rust code versus the original sources (WEB code in this case), the last time this was posted: https://news.ycombinator.com/item?id=21176806 (Though it's not a fair comparison as this particular automatic translation itself started from automatically translated C code, for unclear reasons.)

Probably because there is no automated translator from WEB? And unlikely there will ever be.