Hacker News Reader

Comment by preseinger | Hacker News Reader

it's not possible for human beings to write correct C code, measured over time

this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence

it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees

edit:

> This brings me to my next reason: I have the discipline to write C at a high level.

factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.

View on HN

> it's not possible for human beings to write correct C code, measured over time

I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe.

> you have a professional obligation to use a higher-level language, with stronger guarantees

Oh? So we have professional obligations now? For FOSS? News to me.

I don't get paid for my work. Not yet. So I have no obligation.

And when I do get paid, my code will be in my own safe language.

This accusatory response is exactly the kind of thing that puts a lot of people off Rust.

> factually, you do not. nobody does.

When I say "write C at a high level," I don't mean that I'm perfect. I mean that I write excellent C compared to all C programmers out there.

Engineering is not about perfection; it never was. It's about doing the best we can with the tools that we have.

[1]: https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...

Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."

That is true. I'm repeating what others have judged and told me.

Of course, feel free to judge for yourself.

This could be true if you consider survivor bias.

I'm an experienced C developer and I wouldn't say this. I'm pretty meticulous, I use as much tooling as I can, and I've still written over/underflows, memory corruption, threading heisenbugs, double frees, NULL derefs, etc. etc. etc. My defect rate has gone way down over the years, but that's probably 50/50 experience vs. an attenuation of my ambitions.

I think the proof is in the pudding here. I can't imagine using a messaging client or an email client written in C, and also there isn't much that is written in C anymore even if I wanted to: you're looking at Swift/Java/Kotlin/TypeScript/JavaScript/C#/Vala/Dart/Rust/Go, and maybe C++.

Is anyone writing production servers in C these days? It feels like they're 100% Go and Rust.

There are notable exceptions, in particular I'm thinking about OpenBSD. I think OS dev is a pretty niche area though, especially when you're talking about OpenBSD's wide platform support, so I think it's more the exception that proves the rule than anything.

Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothing “unsafe” happens there surely.

All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.

i'm sure the linux kernel maintainers already know that it's impossible for them to write correct C code, no need to tell them

The Rust compiler developers are well aware that it's not possible to write 100% correct code at scale, not least for their dependencies, LLVM provides Rust with ICE (cases where your program crashes the compiler) and with soundness holes where the LLVM behaviour is definitely wrong but it's arguably exactly why and so until LLVM developers decide why it's wrong and fix it, Rust has to either work around that or accept sub-par results.

Much of the Rust compiler is written in Rust and so has fewer problems.

Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...

If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing wave of the hand - it’s not serious.

So you want something more serious,

https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...

https://security.apple.com/blog/towards-the-next-generation-...

https://www.chromium.org/Home/chromium-security/memory-safet...

https://security.googleblog.com/2022/08/making-linux-kernel-...

Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)

So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.

Lets see how serious those developers get to be around security issues, when liability finally takes off.

I appreciate that you are making an argument and will respond when I get a chance later in the day and after I read a few of the links - I’m familiar with like half of them.

it is not anyone's claim that the existence of C cves means it is impossible to write correct C

the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale

at scale means across a broad demographic of programmers, working on a broad set of programs

if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity

strcpy and pointer arithmetic are basically not possible to get right

we need to move beyond this very low level of abstraction

> it's not possible for human beings to write correct C code

It's not possible for human beings to write correct code.

The hardest bug I ever found in a C program, one that took cumulative weeks of work until a tractable reproduction was found, came down to a ‘<’ that should have been ‘<=’. No language would have stopped that.

Yes, different languages have different levels of expressiveness, and can preclude or expose different kinds of errors. You'll never have a stray pointer in Python, and you'll never OOM making an accidental copy in C.

Not true. Check out CompCert, seL4 etc.

obviously yes

yet c code is inarguably more error-prone than basically any other language

Nope. Many errors in JavaScript, python, PHP, etc are caught at compile time in C.

Of course, the errors that do get through might be more severe in C than in python, but not always.

After all, the most expensive and destructive RCE ever was in a piece of Java software.

I assume this was a logic error, that is, the code as written was a valid C program that didn't do what you meant.

In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.

I don't know why you say that C is bad for exercising error conditions or fuzzing. In my experience, it's the best at those.

It doesn't come with either capability, so you're adding third party tooling to get these working.

Well, sure, but that's true of any language.

Nope, when I write tests in my Rust the out of box cargo test will check those tests pass.

If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.

You said fuzzing and exercising error conditions. Rust's tooling does not do that. You need something to generate those tests.

Fuzzing is still not part of the default Rust tooling.

Mere existence of a test runner is infinitesimal compared to your proposed careful testing. Saying this as someone who wrote my own test runner, it's a few lines of code.

What you mean to say is you have no shot at correct C, and so the language scares you, and you believe since you can't do it nobody does.

It's true that the community at large writes lots of bugs. But that doesn't mean some people aren't productive with the language and write a relatively low number of bugs. There are some projects with better track records at this than others.

no, that is not what i mean to say

at scale, it is not possible for humans to hand-write C programs that are free of segmentation fault class errors

this is not controversial or in any way arguable

Sel4 would like to have a word.

Inb4 you move the goalposts for "at scale". This is an operating system with capability-based access control which is not something that most operating systems even have.

Also the cryptographic constraints are part of the proof system.

I'm not sure Sel4 can be considered "at scale", given the rather extreme amount of effort that went into it.

you just moved the goalposts.

Your opinion is common here. However, you can't just say your opinion is the consensus and that makes people who have other experiences wrong, end of debate. Popularity doesn't indicate truth. I'm sorry you haven't seen it working well, but there are counterexamples where people are productive with a relatively low number of issues.

And yet C code runs the world. You might be right in theory but in practice C is the most successful programming language in history. At work we routinely deploy million+ lines of C in production running large international airlines and airports. And it works.

that C code is prolific is a historical fact, it does not imply anything about efficacy or soundness

"it works" is factually not true, look at ~any CVE

No successful software is bug free. Except for proven correct code like CompCert and seL4 of course.

of course, but that's not the point being made here

Historical accident, due to UNIX winning out the server room.

In early 1980's it was only running Bell Lab's world and a couple of universities that got hold of the source tapes.

The success of UNIX and C is no accident.

> it's not possible for human beings to write correct C code, measured over time

I agree that C the programming language does not help you avoid memory errors, however, saying it's impossible is too binary. People do make mistakes, whether it's copy editors missing a typo or professional chefs misremembering whether they stocked an ingredient. Projects written in C need longer periods of code review and testing, but they can be made right. The code that took us to the moon was written in assembly after all.

Reply on news.ycombinator.com