Announcement

Collapse
No announcement yet.

GNU libmicrohttpd 0.9.57 Brings Significant Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by DrYak View Post
    So you consider your self "way too stupid to write anything in C or Rust" but think that somehow this shouldn't stop you from debating about computer languages that you don't even understand ?
    FYI: that's what stupid people usually do, no surprises there.

    Comment


    • #12
      Originally posted by DrYak View Post
      So you consider your self "way too stupid to write anything in C or Rust" but think that somehow this shouldn't stop you from debating about computer languages that you don't even understand ?
      I have coded in C, or at least attempted to do so. So I know how tricky it is and how much problems I had with it. I know how easy it was for me to shoot myself in the foot with C. I experienced all those segmentation faults, and all kinds of problems such as buffer overflows, index errors, etc.
      I code in other languages and find it much more enjoyable.
      I admit that I am too stupid for C. But there are other programmers out there who are too stupid for C but refuse to admit so, hence there is much vulnerable software out there.
      I've looked at Rust and find it appealing because it resolves much of the problems with C, however I still find I am too stupid for Rust.

      Linus Torvalds refuses to accept any C++ in Git, not because people are too stupid to understand C++.

      Comment


      • #13
        Originally posted by trivialfis

        Putting many restrictions inside a language can provide safety. But once you know why those restrictions are added and how to deal with it, you won't need those to be built in.
        I think this could not be further from the truth. The heartbleed bug was painfully obvious... ...once you've seen it. The reasons for range checks are well-known, but those bugs keep showing up. Many C standard library functions are unsafe and using them in an intuitive way automatically results in a vulnerability. You can either ban their use in your code which is effectively equivalent to using a safe language or, since you know why those would be restricted, use them and always remember to insert the necessary checks yourself. But why would you want to do that when a compiler can do that for you? At some point you'll either do one check less than necessary and have a vulnerability or one check too much and suffer a performance penalty. A compiler that is supplied with sufficient information can do the check once and propagate the information that the check has been done to all reuses of that index.

        Comment

        Working...
        X