3 ms·

> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulner

> I do not code any C, but I assure you if I did I'd consider it part of proper programming practice and discipline to write code that avoids those exact vulnerabilities you suggest. And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. It's the same as hospitals. You can't just say "who needs checklists? Surgeons and assistants should be disciplined enough to not make mistakes in the first place!". In an ideal world they would be, but in this world, they're not and never will be. Not being able to admit this is how you end up with surgery on your left knee when it was meant to be your right. Accept that no-one is 100% perfect, 100% of the time - let alone you - and mould your development around these (very human) failings. "Disciplined programming" will never be as safe as "disciplined programming with guard-rails built into the language". Weigh up the trade-offs - sometimes the performance gain is worth the risk, sometimes it's not.

orange8 7y ago
> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence
- jolux 7y ago
  You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.
  - orange8 7y ago
    > You appear to assume I like your choice of words, but no. I disagree with that assumption.
    - jolux 7y ago
      Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.
      - orange8 7y ago
        And I will observe, once again, that all that means nothing without best practice and discipline.
        jolux 7y ago
        It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.
        orange8 7y ago
        If its about clean code, all that means nothing without discipline and good practice. Clean code is something humans do, not linters, compilers or languages.
        jolux 7y ago
        Have you written a significant amount of C? I ask this because you said you don't write any of it in a comment in which you suggested its problems could be avoided by following best practices and being disciplined. There are a set of problems that languages have that just cannot be solved by humans adopting better discipline or best practices. C's type system is unsafe, and its memory handling is an adjacent and related problem. Tools like Valgrind exist and they are considered best practices when writing C, but they do not claim and cannot hope to make it memory safe. Fixing that problem requires language-level intervention, and this has been solved most of the time with better static type systems. Anyone who writes a lot of C will tell you this, it is an inherent pitfall of the language's design and one to be avoided when designing new languages.

orange8 7y ago

> And yet all of those vulnerabilities came from hundreds of developers who shared the same misplaced confidence in their own abilities. This is a good example of a straw man argument. A comment about a programming language or framework not being a silver bullet to clean code has suddenly been twisted into a comment about developers with misplaced confidence in their abilities. How exactly does using best practice in and discipline equate to overconfidence?! good practice and discipline ≠ misplaced confidence

jolux 7y ago
You appear to assume that applying good practice and discipline is a route to eliminating these problems rather than mitigating them.
- orange8 7y ago
  > You appear to assume I like your choice of words, but no. I disagree with that assumption.
  - jolux 7y ago
    Well, in that case, I will observe that static type systems and memory safety do eliminate the problems of ill-typed programs and memory unsafe programs, and that these are highly desirable properties for a lot of systems.
    - orange8 7y ago
      And I will observe, once again, that all that means nothing without best practice and discipline.
      - jolux 7y ago
        It doesn't mean nothing without those things though. It means exactly the same whether or not you follow best practices or have discipline, that's the entire point. It will not ensure your code is good, it will merely ensure it does not have those problems.
        orange8 7y ago
        If its about clean code, all that means nothing without discipline and good practice. Clean code is something humans do, not linters, compilers or languages.
        jolux 7y ago
        Have you written a significant amount of C? I ask this because you said you don't write any of it in a comment in which you suggested its problems could be avoided by following best practices and being disciplined. There are a set of problems that languages have that just cannot be solved by humans adopting better discipline or best practices. C's type system is unsafe, and its memory handling is an adjacent and related problem. Tools like Valgrind exist and they are considered best practices when writing C, but they do not claim and cannot hope to make it memory safe. Fixing that problem requires language-level intervention, and this has been solved most of the time with better static type systems. Anyone who writes a lot of C will tell you this, it is an inherent pitfall of the language's design and one to be avoided when designing new languages.