4 ms·

And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security

by lisper 4y ago

And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.

elcomet 4y ago
That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.
- lisper 4y ago
  Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.
- sitkack 4y ago
  What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic. If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks. If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks. How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness. C was an inside job.
- Gibbon1 4y ago
  There is something backwards about how safety checks are done in C. First it's up to the programmer to put them in. Then hopefully the compiler will optimize away the unneeded ones. If the programmer though biffs and forgets then oops. And of course classically we blame the programmer not the system he's been forced to work under. That seems like a reasonable thing in 1982. Which is 40 years ago. It would be better if the compiler implemented the checks automagically and removed ones it knows it doesn't need. And bonus, if the programmer puts one in, leave it alone.
ryandrake 4y ago
> I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s sloppiness. I feel end users pay a high cost for all this runtime checking and all these frameworks and levels of abstraction.
- quickthrower2 4y ago
  Is Rust slower then C in general though? And how much are you paying? Probably in true terms it costs less if there are fewer bugs and vulns.
- lisper 4y ago
  First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time. And second, would you really rather deal with security holes on an on-going basis? The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible to perform even basic sanity checks at compile time [EDIT: or even at run-time for that matter]. For example: int x[10]; ... int y = x[11]; In any sane language, that would be a trivially-checkable compile-time error. But in C it is not because there are all kinds of things that could legally happen where the ellipses are that would make this code not violate any of C's safety constraints. That is the problem with C, and it is a fundamental problem with C's design, that it conflates pointers and arrays. C was designed for a totally different world, and it is broken beyond repair.
  - jsnell 4y ago
    Bad example. There's nothing[0] you could put in the ellipsis to make that code valid, and both gcc and clang will warn about it (clang on defaults, gcc with -Wall). [0] Ok, I guess you could #define x something, but that's not interesting from a static analysis perspective.
TylerE 4y ago
You're assuming that safety features will prevent security bugs. I think that is...optimistic at best. Yes, they can defeat a few classes of exploits, but generally not the ones that lead to really bad outcomes.
- mcpherrinm 4y ago
  > The Chromium project finds that around 70% of our serious security bugs are memory safety problems. > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues Memory safety is a leading source of serious bugs in a big group of operating systems, browsers, image and file parsers, and more. It does seem likely we can stop this, and it doesn’t seem likely to me we can fix it in C. We have tried and failed for years at that.
  - pjmlp 4y ago
    Solaris SPARC is the first that has suceeded at it, and now others follow it, how? Hardware memory tagging, the language itself is beyond hope.
- lisper 4y ago
  I can't respond to that unless you are more specific about what are "the ones that lead to really bad outcomes". There are a lot of arbitrary-code-execution attacks that are enabled by buffer overflows, and IMHO that's as bad as it gets. There is absolutely no legitimate excuse for a buffer overflow in today's world. Switching to safe(r) language won't prevent all attacks, but it will make a big dent.
- sitkack 4y ago
  If you remove the mechanically preventable bugs from being a consideration, by definition the only one you now need to focus on are the ones NOT prevented by mechanism. How is this not a win? We only have so many decisions we can make per day.
  - tempest_ 4y ago
    A lot of people make perfect the enemy of good.

by lisper 4y ago

elcomet 4y ago

That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.

lisper 4y ago
Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.
sitkack 4y ago
What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic. If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks. If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks. How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness. C was an inside job.
Gibbon1 4y ago
There is something backwards about how safety checks are done in C. First it's up to the programmer to put them in. Then hopefully the compiler will optimize away the unneeded ones. If the programmer though biffs and forgets then oops. And of course classically we blame the programmer not the system he's been forced to work under. That seems like a reasonable thing in 1982. Which is 40 years ago. It would be better if the compiler implemented the checks automagically and removed ones it knows it doesn't need. And bonus, if the programmer puts one in, leave it alone.

ryandrake 4y ago

> I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s sloppiness. I feel end users pay a high cost for all this runtime checking and all these frameworks and levels of abstraction.

quickthrower2 4y ago
Is Rust slower then C in general though? And how much are you paying? Probably in true terms it costs less if there are fewer bugs and vulns.
lisper 4y ago
First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time. And second, would you really rather deal with security holes on an on-going basis? The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible to perform even basic sanity checks at compile time [EDIT: or even at run-time for that matter]. For example: int x[10]; ... int y = x[11]; In any sane language, that would be a trivially-checkable compile-time error. But in C it is not because there are all kinds of things that could legally happen where the ellipses are that would make this code not violate any of C's safety constraints. That is the problem with C, and it is a fundamental problem with C's design, that it conflates pointers and arrays. C was designed for a totally different world, and it is broken beyond repair.
- jsnell 4y ago
  Bad example. There's nothing[0] you could put in the ellipsis to make that code valid, and both gcc and clang will warn about it (clang on defaults, gcc with -Wall). [0] Ok, I guess you could #define x something, but that's not interesting from a static analysis perspective.

TylerE 4y ago

You're assuming that safety features will prevent security bugs. I think that is...optimistic at best. Yes, they can defeat a few classes of exploits, but generally not the ones that lead to really bad outcomes.

mcpherrinm 4y ago
> The Chromium project finds that around 70% of our serious security bugs are memory safety problems. > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues Memory safety is a leading source of serious bugs in a big group of operating systems, browsers, image and file parsers, and more. It does seem likely we can stop this, and it doesn’t seem likely to me we can fix it in C. We have tried and failed for years at that.
- pjmlp 4y ago
  Solaris SPARC is the first that has suceeded at it, and now others follow it, how? Hardware memory tagging, the language itself is beyond hope.
lisper 4y ago
I can't respond to that unless you are more specific about what are "the ones that lead to really bad outcomes". There are a lot of arbitrary-code-execution attacks that are enabled by buffer overflows, and IMHO that's as bad as it gets. There is absolutely no legitimate excuse for a buffer overflow in today's world. Switching to safe(r) language won't prevent all attacks, but it will make a big dent.
sitkack 4y ago
If you remove the mechanically preventable bugs from being a consideration, by definition the only one you now need to focus on are the ones NOT prevented by mechanism. How is this not a win? We only have so many decisions we can make per day.
- tempest_ 4y ago
  A lot of people make perfect the enemy of good.