Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

21–30 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#21
post #14
post #10

Earlier quoted context omitted.

Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C. (no true Scotsman)

> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?

I think his comment was facetious. I think the clue is "no true scotsman," which is a type of fallacy. I think the point is that it's assumed to be better because of the use of "modern," and that it's only valuable if it's rewritten in something modern. Perhaps it's a joke about how old code is actually fine, and that people who get excited about the cutting-edge technology could chill a little bit. Maybe it's just a mockery of the previous arguments.

Re: Why you should, actually, rewrite some of it in Rust

#22
post #4

Earlier quoted context omitted.

If you rewrote only part of a large C++ project in Haskell, is there a way to link it back in again?

Call Haskell from C (not C++) seems pretty easy: - [Calling Haskell from C - HaskellWiki]( https://wiki.haskell.org/Calling_Haskell_from_C ) And the FAQ on the Haskell wiki directly addresses this too: - https://wiki.haskell.org/Introduction#I_already_have_a_large... . So apparently it is doable!

It pulls in a huge runtime system, though (including stuff like garbage collection). This makes it much heavier than calling some Rust code.

Re: Why you should, actually, rewrite some of it in Rust

#23

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

Re: Why you should, actually, rewrite some of it in Rust

#24
post #4
post #2

Or even better, Haskell!

If you rewrote only part of a large C++ project in Haskell, is there a way to link it back in again?

It definitely can, but if you're asking for an out-of-the box support, then it's probably not as easy to use as Rust. Then again, if you plan to rewrite your code base, then why not invest -- typed IO is a big thing.

Re: Why you should, actually, rewrite some of it in Rust

#25
post #23

Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

The problem is they implementing their own memory management on top of the standard primitives; they never sent unallocated memory to the client.

Re: Why you should, actually, rewrite some of it in Rust

#26
The author focuses on rewriting low-level media decoders in Rust. I have bit of experience in this area. I've been slowly working on an MPEG2 binary subtitle decoder in Rust: https://github.com/emk/subtitles-rs

A while back, I ran my subtitle decoder through "cargo fuzz", and I was pleasantly surprised at the results: Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before they could compromise security. If I'd written this code in C, several of those errors would have been exploitable. I like to think I'm a lot more paranoid than the average programmer. But the MPEG2 format is gnarly and, sooner or later, I'll miss a potential overflow when bit shifting, or get confused following internal "pointers" in a subtitle packet.

Rust has a few advantages for this work:

1. Rust does not require a garbage collector or other specialized runtime. This makes it far easier to pretend to be boring C code. This is a significant advantage over some other excellent languages like Haskell, etc., which require non-trivial runtimes.

2. Rust is very fast by default. For low-level programming, this matters.

3. The Rust infrastructure for testing and fuzzing is surprisingly good and easy to use, which makes it easier to produce bullet-proof libraries.

The downside is that even if you're already familiar with C++, it's probably going to take a couple of weeks to become comfortable with Rust. And if you don't really understand stacks, heaps, memory layout and references, it may take even longer.

I do agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises. But it's going to require literally billions of dollars of programmer time to put a dent in this problem.

Re: Why you should, actually, rewrite some of it in Rust

#27
post #7
post #3

C can be safe if you use Turing incomplete libraries that have been verified. It's the YOLO ad hock parsers that get you in trouble.

I am not sure if you are serious or not. How does verification prevent buffer overflows? It can reduce their frequency, but you can never know you got them all. They find issues in libCURL and openSSL that have existed for years. Very few people are better than the people working on those libraries. It is better to be safe by default then add risk only when you need it. I say this as a C++ developer, I think const sh…

It was probably the "Turing-incomplete" part that prevents buffer overflows. Easier to reason about/verify.

Re: Why you should, actually, rewrite some of it in Rust

#28
post #14
post #10

Earlier quoted context omitted.

Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C. (no true Scotsman)

> Or just rewrite it in modern C. This is sane and doable in a short period of time. What do you call modern C?

same question applies to C++. every new version of C++ is the modern version for a while…
Post reply on HN