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

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

91–100 of 504 posts

Re: Getting Past C

#91

Post by eduren »

aaron-lebo wrote: post #4

Outside of the language war bubble it's really great to see a post like this. Practical concerns, reasonable advantages/disadvantages of each language, a real project dealing with real timelines. Thanks!

I'm excited to see where this goes because it could go a long way towards providing concrete data for the large "work to replace old infrastucture C code with (Rust||Go||Modern C++)" discussion that has been taking place.

More data points will help to inform discussion, or at the very least add structure to the flame wars.

Re: Getting Past C

#92

Post by staticassertion »

lacampbell wrote: post #56
Animats wrote: post #42

Earlier quoted context omitted.

The track record of two decades of CERT advisories for buffer overflows suggests that doesn't work in practice.

Just because people fail to do something doesn't mean it's not both possible and easy.

While this is technically true, it isn't practically true. "Easy" is certainly false.

I really enjoyed these posts by strncat:

https://www.reddit.com/r/programming/comments/5krztf/rust_vs...

> It's scary how unfamiliar C programmers are with the rules of the language they're using... it's very difficult to write correct / secure C code without undefined behavior even when you know the rules.

[...]

> It's not feasible to avoid undefined behavior at scale in C or C++ projects. It's simply infeasible. They are not usable as safe tools without using a very constrained dialect of the languages where nearly all real world code would be treated as invalid, with annotations required to prove things to the compiler and communicate information about APIs to it.

Re: Getting Past C

#93

Post by jstimpfle »

aaron-lebo wrote: post #4

Outside of the language war bubble it's really great to see a post like this. Practical concerns, reasonable advantages/disadvantages of each language, a real project dealing with real timelines. Thanks!

Was going to say the same. In the past ESR has come across as a patently arrogant gun maniac, but the first part of this post is great for all the reasons you mentioned.

(What irritated me though was the switch to first-person narrative at the end).

Re: Getting Past C

#94

Post by steveklabnik »

lacampbell wrote: post #63
staticassertion wrote: post #40

Earlier quoted context omitted.

Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax. Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires…

Would you care to provide a short rust implementation of reading an arbitrary length string from standard input? I have rust installed. I would be curious to benchmark it and see if is indeed faster than the same thing in C, using a user-defined bounds checked array.

I'm not going to make any performance claims, but in the interest of sample code, https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#me... has a very small program that does this in the most straightforward way. (You'll have to wrap it in `fn main()`, we don't show that in examples in the docs)

If you want a true speed comparison, you'd have to define more than just "read an arbitrary string". For example, encoding requirements. Your C is going to treat it as just a bag of bytes, and you can do that in Rust too, but it's not the most natural way; you'd convert to UTF-8, which isn't free. Stuff like that.

Re: Getting Past C

#95

Post by kazinator »

jdcarter wrote: post #84
jstimpfle wrote: post #58

Earlier quoted context omitted.

I see where you are going, but I don't get how you get from 4 to 5 to 100 to 1500?

I can answer: safe read/write from a simple system call can be "easy." Safe read from the network, possible but no longer easy. Safe call to ioctl, which can literally do anything with any device driver... is a "safe" version of that even possible?

ioctl is a marshaling mechanism that can represent a library API of almost unlimited proportions and variety. A safety wrapper basically has to target the specific functions, rather than ioctl itself. That has happened within Unix, with some library functions having originated as wrappers around ioctls.

Re: Getting Past C

#96

Post by lacampbell »

_sh wrote: post #89
lacampbell wrote: post #63

Earlier quoted context omitted.

Would you care to provide a short rust implementation of reading an arbitrary length string from standard input? I have rust installed. I would be curious to benchmark it and see if is indeed faster than the same thing in C, using a user-defined bounds checked array.

It's not so much a question of benchmarks, it's that one of the standard C tools for reading an arbitrary string from standard input is gets(). And if you reach for that from the standard toolbox, you've failed before you've started.

Many rust advocates talk about the performance cost of doing things safely in C, and inform me that rust has "Zero-cost abstractions". So it's fairly natural I ask for something I can benchmark.

Re: Getting Past C

#97

Post by dragontamer »

falcolas wrote: post #38
leoedin wrote: post #18

Earlier quoted context omitted.

Microcontrollers aren't moving towards application level processors like the Raspberry Pi uses, they're moving towards low power ARM cores like the Cortex M0/M3/M4. It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature. Current generation ARM Cortex M0 devices are available at a similar cost and with significant performance gains, with the benefit that if y…

I'd love to read more about this microcontroller migration towards ARM - any hints on where to look?

I dunno if its a 'major' migration, but NXP is basically doubling down on ARM-only architectures.

Microchip / Atmel (same company now btw) are doing an "everything and anything" strategy. PIC, ATTiny, ATMega, UC3, AND ARM chips are available from them.

It seems like the smaller 8-bit microcontrollers use less power and have better features for embedded engineers (ie: ADC converters, PWM, Real-time clocks, deeper sleep modes).

While ARM has the general benefit of being much faster from a computational perspective. But if you want to read the voltage from a simple thermo-resistor and then output it on an I2C bus... I'm thinking a classic 8-bit AVR is going to be superior over any ARM.

--------

I'm still seeing 8051 stuff pop up everywhere, and that thing was supposedly dead years ago.

Re: Getting Past C

#98

Post by steveklabnik »

afarrell wrote: post #78
panic wrote: post #69

Earlier quoted context omitted.

And it only takes one programmer mistake to bring the whole house of cards down. Isn't this also true of Rust, with its unsafe keyword? None of these languages are completely safe against programmer mistakes.

Is the use of the unsafe keyword a default? I don't know Rust, but from a user interface perspective, it sounds like it has an affordance of "Hey! Pay particular attention to this bit because it is risky!"

It is very much not the default.

Re: Getting Past C

#99

Post by wmf »

lacampbell wrote: post #88
staticassertion wrote: post #67

Earlier quoted context omitted.

I didn't claim that rust would be faster than C (not that it can't be) in that situation. I would expect very similar performance. I'm not feeling very well unfortunately, not really in the mood to code.

I just keep hearing about how rust handles safe bounds checked arrays with (and I quote) "Zero-cost abstractions", which to me implied it would be faster than C, since C pays some performance penalty by branching. Hope you feel better soon.

"Zero-cost abstraction" really means zero additional cost beyond what is required. So Rust still pays a cost for bounds checking, but it's the same cost as if you optimally hand-coded the bounds check in C.

Re: Getting Past C

#100

Post by rnestler »

lacampbell wrote: post #63
staticassertion wrote: post #40

Earlier quoted context omitted.

Because your 'safe' implementation will certainly have a performance cost, and won't be the default. This is why, despite C++ providing std::array, you'll still find buffer overflows in C++ code. C++'s std::array provides the safe 'at' function but you're opting into a performance penalty and it's not the more familiar [] syntax. Rust arrays/ vectors are safe-by-default. To use the unchecked, unsafe version requires…

Would you care to provide a short rust implementation of reading an arbitrary length string from standard input? I have rust installed. I would be curious to benchmark it and see if is indeed faster than the same thing in C, using a user-defined bounds checked array.

Did you mean something like this?

    use std::io::{self, Read};
    fn main() {
        let stdin = io::stdin();
        let mut data = vec![];
        stdin.lock().read_to_end(&mut data)
            .expect("Reading stdin failed");
    }
Post reply on HN