5 ms·

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 evalua

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.

jtorsella 3y ago
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.
- preseinger 3y ago
  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
- tialaramex 3y ago
  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.
- pjmlp 3y ago
  Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
  - jtorsella 3y ago
    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.
    - pjmlp 3y ago
      So you want something more serious, https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html 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.
      - jtorsella 3y ago
        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.
    - preseinger 3y ago
gavinhoward 3y ago
> 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/MEMORY_BUGS.md https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...
- tourist2d 3y ago
  Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."
  - gavinhoward 3y ago
    That is true. I'm repeating what others have judged and told me. Of course, feel free to judge for yourself.
  - amoss 3y ago
    This could be true if you consider survivor bias.
  - camgunz 3y ago
    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.
kps 3y ago
> 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.
- deterministic 3y ago
  Not true. Check out CompCert, seL4 etc.
- preseinger 3y ago
  obviously yes yet c code is inarguably more error-prone than basically any other language
  - lelanthran 3y ago
    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.
- tialaramex 3y ago
  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.
  - gavinhoward 3y ago
    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.
deterministic 3y ago
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.
- preseinger 3y ago
  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
  - deleted 3y ago
    [deleted]
  - deterministic 3y ago
    No successful software is bug free. Except for proven correct code like CompCert and seL4 of course.
    - preseinger 3y ago
      of course, but that's not the point being made here
- pjmlp 3y ago
  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.
  - deterministic 3y ago
    The success of UNIX and C is no accident.
hgs3 3y ago
> 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.
asveikau 3y ago
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.
- preseinger 3y ago
  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
  - throwawaymaths 3y ago
    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.
    - int_19h 3y ago
      I'm not sure Sel4 can be considered "at scale", given the rather extreme amount of effort that went into it.
      - throwawaymaths 3y ago
        you just moved the goalposts.
  - asveikau 3y ago
    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.

jtorsella 3y ago

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.

preseinger 3y ago
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
tialaramex 3y ago
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.
pjmlp 3y ago
Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/cvssscoremin-7/cvssscoremax-7.99/Linux-Linux-Kernel.html https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
- jtorsella 3y ago
  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.
  - pjmlp 3y ago
    So you want something more serious, https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/ https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... https://security.googleblog.com/2022/08/making-linux-kernel-exploit-cooking.html 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.
    - jtorsella 3y ago
      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.
  - preseinger 3y ago

gavinhoward 3y ago

> 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/MEMORY_BUGS.md https://git.gavinhoward.com/gavin/bc/src/branch/master/MEMOR...

tourist2d 3y ago
Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."
- gavinhoward 3y ago
  That is true. I'm repeating what others have judged and told me. Of course, feel free to judge for yourself.
- amoss 3y ago
  This could be true if you consider survivor bias.
- camgunz 3y ago
  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.

kps 3y ago

> 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.

deterministic 3y ago
Not true. Check out CompCert, seL4 etc.
preseinger 3y ago
obviously yes yet c code is inarguably more error-prone than basically any other language
- lelanthran 3y ago
  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.
tialaramex 3y ago
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.
- gavinhoward 3y ago
  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.

deterministic 3y ago

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.

preseinger 3y ago
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
- deleted 3y ago
  [deleted]
- deterministic 3y ago
  No successful software is bug free. Except for proven correct code like CompCert and seL4 of course.
  - preseinger 3y ago
    of course, but that's not the point being made here
pjmlp 3y ago
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.
- deterministic 3y ago
  The success of UNIX and C is no accident.

hgs3 3y ago

> 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.

asveikau 3y ago

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.

preseinger 3y ago
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
- throwawaymaths 3y ago
  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.
  - int_19h 3y ago
    I'm not sure Sel4 can be considered "at scale", given the rather extreme amount of effort that went into it.
    - throwawaymaths 3y ago
      you just moved the goalposts.
- asveikau 3y ago
  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.