Hacker News Reader

Comment by concede_pluto | Hacker News Reader

> Can I not write a well designed and correct program in C?

We have decades of coredumps and exploits to convince us that nobody can. How many well-known apps can you name that have never blown up randomly? I can't think of a single one. How much more failure until it's reasonable to think that C requires an inhuman level of perfection and almost any alternative would be an improvement?

I hear good things about seL4 but that wasn't written so much as translated from Haskell during a formal process that makes Rust look like finger painting.

View on HN

> I hear good things about seL4 but that wasn't written so much as translated from Haskell during a formal process that makes Rust look like finger painting.

It's actually more fun than that. They have two implementations of seL4, and they use formal proofs to show that the Haskell model is identical to the C implementation. How much fun is that! /s

GNU ls has never segfaulted or otherwise blown up for me. :)

It has segfaulted for other people though: https://lists.gnu.org/archive/html/bug-coreutils/2006-11/msg...

GNU Bash segfaults for me whenever I type ~[tab]. Thankfully this only happens on the small few systems I had to manually patch after the epic Bash vulnerability a couple of years ago - older internal systems that are still in use for historic reasons rather than regularly relied upon in production. So it's never been annoying enough to fix.

It will. No program is perfect.

Rust and Go advocates will have you think that they have conquered security via the memory mgmt and API front but there is still the off chance they haven't..or that the SA (what is left of that maligned profession outside playbooks and the devops marketing you read here and online) has allowed you a chance for glory.

There are basically two rules to a well written C program (if I am now allowed to speak despite the public outcry).

1. Do not trust user input. This is a cardinal rule in whatever source. If the rule were followed vigorously in every case there would be 90% less exposure. When you take user input, filter. 2. Learn the standard and stick to it.

Finally #3 (unix) Write an application to do a certain thing well.

(vouched)

On #1, having just stumbled across a deserializer that can be commanded to allocate a 2^63 byte buffer, I agree 110%.

On #2, the problem is that the standard says things like "walking off the end of an array is undefined behavior" and "use after free is undefined behavior" yet we don't seem to have any programmers who can be trusted to reliably avoid these problems with zero runtime checking.

Reply on news.ycombinator.com