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

Building on Rock, Not Sand

robert.ocallahan.org

Post reply on HN
Print view View original

11–20 of 112 posts

Re: Building on Rock, Not Sand

#11

Post by Kliment »

brainwipe wrote: post #3
dsign wrote: post #2

We run high-load web services in something-other-than-c with managed memory and checked array access. It is native, 8/9 as fast as C, and it works. We will never have the budget to pay for the additional 1/9th that C would afford us, in terms of security concerns. Yet, everyday, I have to field questions about why our low-level, network-facing system code is not written in C... old prejudices die hard.

Have you ever been asked to switch down into Assembler mid-function in C to solve timing issues in the hardware? I have... but that was 20 years ago!

All the time, but then I do a lot of embedded programming.

Re: Building on Rock, Not Sand

#13

Post by pmontra »

Nothing comes for free. I expect to have to trade something for security. It seems we have to trade speed and size. Ok, it shouldn't matter to us: this should not be developers' call. Instead it should go into a costs benefit matrix with plenty of other technical and not technical stuff. Developers will advise on their part of the matrix, marketers on their own, etc. Managers will make the decision and be held responsible for security breaches (or plauded for the lack of) as much as for every other feature of the product.

Re: Building on Rock, Not Sand

#14

Post by JustAMinute »

dsign wrote: post #2

We run high-load web services in something-other-than-c with managed memory and checked array access. It is native, 8/9 as fast as C, and it works. We will never have the budget to pay for the additional 1/9th that C would afford us, in terms of security concerns. Yet, everyday, I have to field questions about why our low-level, network-facing system code is not written in C... old prejudices die hard.

If you haven't written a version of it in C, how do you know it's 8/9 as fast. What are you basing that figure on.

Re: Building on Rock, Not Sand

#15

Post by blub »

What if there is just not enough interest in improving C++'s safety? Or in improving safety at all? That's the scary thought.

I also have to point out that these pesky C buffer overflows are trivial to avoid in C++: just use std::vector::at.

Re: Building on Rock, Not Sand

#16

Post by ryansama »

It would be nice to have more healthy competition in this space. Any suggestions?

Would it not be great to have a language as powerful as Rust but with the ease of Go?

Anyhow, must be like CAP. You can't have everything in a language.

Re: Building on Rock, Not Sand

#17

Post by sanxiyn »

Note that you can write safe C code. seL4 is written in C! (And verified in Isabelle.) If that is too hard core, PolarSSL is a normal looking C code, which still has been proved to lack any buffer overflow. https://trust-in-soft.com/polarssl-verification-kit/ has details.

On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof.

Re: Building on Rock, Not Sand

#18

Post by sanxiyn »

pmontra wrote: post #13

Nothing comes for free. I expect to have to trade something for security. It seems we have to trade speed and size. Ok, it shouldn't matter to us: this should not be developers' call. Instead it should go into a costs benefit matrix with plenty of other technical and not technical stuff. Developers will advise on their part of the matrix, marketers on their own, etc. Managers will make the decision and be held respon…

> It seems we have to trade speed and size.

Why do you think so?

Re: Building on Rock, Not Sand

#19

Post by bsder »

petiepooo wrote: post #8

Another rust proponent lecturing the world on how they should rewrite everything in rust. yawn

You might want to look up the fact that the author is a HEAVY FREAKIN' DUTY C++ PROGRAMMER before making uninformed whingeing.

http://robert.ocallahan.org/2017/09/rr-50-released.html http://robert.ocallahan.org/2017/07/confession-of-cc-program...

Re: Building on Rock, Not Sand

#20

Post by jabot »

sanxiyn wrote: post #17

Note that you can write safe C code. seL4 is written in C! (And verified in Isabelle.) If that is too hard core, PolarSSL is a normal looking C code, which still has been proved to lack any buffer overflow. https://trust-in-soft.com/polarssl-verification-kit/ has details. On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof.

I think the seL4 kernel rather proves that you can write safe haskell, verify it, and then transpile that to C.

That's different from directly writing C...

Post reply on HN