4 ms·

> Heartbleed is a symptom of bad programming, not a bad language. Okay, so your claim is tantamount to "every major C program is badly programmed", because eve

> Heartbleed is a symptom of bad programming, not a bad language. Okay, so your claim is tantamount to "every major C program is badly programmed", because every major C program has memory related bugs. If it's really bad programming, not a bad language, why is it that C is so much more often poorly programmed than, say, Python? If it's C programmers, not the C language, then we should avoid C because that's the easiest way to avoid these terrible C programmers. > C is "less secure" because it allows the programmer to do possibly-unsafe things at their own discretion. The alternative is to flat-out ban those things. That's not the only alternative, you're just ignorant of the alternatives.

xamuel 11y ago
>why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. >That's not the only alternative Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine).
- copsarebastards 11y ago
  > It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.

xamuel 11y ago

>why is it that C is so much more often poorly programmed than, say, Python? It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. >That's not the only alternative Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine).

copsarebastards 11y ago
> It's kind of like saying: trauma surgeons must be more dangerous than pediatricians, because so many more patients die in the care of a trauma surgeon than in the care of a pediatrician. It ignores the fact that you wouldn't send a pediatrician to such a difficult patient as you'd send a trauma surgeon to. You wouldn't use Python in a lot of the places you'd use C because the performance would be "shaggy puppy meets Godzilla" lousy. You can make any argument by analogy. > Suppose I've established that the fastest way the computer can do X involves having the CPU (which only knows machine code, no magical languages) access a memory location without checking if it's in bounds. Either the language allows me to program that, or it doesn't. If it does, then Heartbleed-like bugs are possible. QED. Suppose we don't suppose things that are wrong. Static type checking can check bounds at no runtime cost this in many cases. Like I said, your argument is based on ignorance of the alternatives. > Alright, there's technically one other alternative, require the programmer to formally proof-verify that the code does as it's supposed to. I hope that this will become more practical within my daughter's lifetime (it probably won't within mine). I'm not hoping for 100% formal verification here, I'm merely hoping to be significantly better than C. That's a very low bar: C does very little checking. Why on earth would you be opposed to this? In fact, I don't think we'll ever be able to 100% formally verify that a program does what it's supposed to. You can verify some things, like memory access, but in the end we'll never be able to 100% verify that the thing we are verifying is the desired behavior. Look, I'm not criticizing the people who made C or the people who wrote tons of code in C. C was a great language in its time. But it's literally 4 decades old: it would be unreasonable to expect it to not show signs of age.