6 ms·

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mi

Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. That's billions of human beings wasting hours either changing all their passwords or having their money, identities, medical records, and more stolen because they didn't. Having their accounts hijacked. For all we know totalitarian governments have already exploited this to monitor citizens and torture or kill them. If that isn't enough, how about goto fail? All the IIS exploits in v4/5? Various Windows RPC overflows, WMF overflows, SQL Slammer, et al? How many billions in damages have been caused by stack smashing and buffer overflows? How many millions of hours of manpower wasted cleaning up after these errors? Toyota killed some people because their dumb code overwrote memory, blasting the OS task tables causing the watchdog task to stop getting CPU time, meaning nothing provided a stopgap against unintended acceleration. People are literally dying because we can't fucking let go of C. C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents". We've been trying to "drive better" for decades (Valgrind, lint, code reviews, static analysis tools, education, ASLR, NX protection, et al). We still regularly see massive security-smashing epic failures. It hasn't worked. Furthermore the C standard library has been proven turing-complete for ROP gadgets in the presence of a buffer overflow. So no matter what you do, the presence of a single stack smash is enough to allow code execution, subject to payload size limits and execution time. At some point we have to admit C is no longer acceptable. Not for libraries, not for drivers, not for operating systems. It has to go. All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes. Software allows us as programmers to greatly magnify our impact on the world; we like to think of that in positive ways. But the inverse is also true: thanks to the continued use of non-memory-safe languages we have the power to negatively affect the world on a massive scale. It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period.

pjmlp 12y ago
The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.
- feadog 12y ago
  So they could implement SpaceWar on the PDP-11.
raould 12y ago
i registered just to say, "you're hired!"
wtracy 12y ago
It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!
- sixbrx 12y ago
  Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.
  - wtracy 12y ago
    Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.
- kibwen 12y ago
  I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.
  - mwcampbell 12y ago
    I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.
    - Pacabel 12y ago
      What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening. There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist. C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations. It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.
theseoafs 12y ago
> It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. And since memory-safe languages are written in non-memory-safe languages (i.e. C and C++), writing code in them is unethical as well, right?
- pjmlp 12y ago
  Well, most implementations of Ada, Oberon and Modula-2 compilers among many others were boostraped, no C code in sight.
chillingeffect 12y ago
How about if you're developing in a field where the overhead of higher-level languages would prohibit the device from being made at all? Do you just put on your idealist hat and say, "Sorry! I can't develop a medical device for you. You'll just have to die. At least no one was required to be careful about their programming."
Pacabel 12y ago
So what other language can we use today on basically any imaginable platform, while still retaining the extreme degree of control, the excellent interoperability, and the near-optimal runtime performance of C? Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response. While there may be some validity to your claim about "billions of human beings wasting hours" due to vulnerabilities in C code, we can't forget that the alternatives would also suffer from significant forms of waste. If using a language with slower runtime performance, for example, people will need to wait longer for their computations to complete. More powerful, or even just more, hardware will be needed to alleviate these delays. Slower runtime performance also often results in much higher energy consumption. The costs just keep adding up and up. Forcing billions of people to use far less efficient software, while requiring far more powerful hardware, on a continual and ongoing basis, for decade upon decade, could very well generate waste that far, far exceeds that of dealing with an occasional flaw in widely-used C code. I just can't seriously buy your "All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes." argument. C won't be going anywhere until somebody provides a practical alternative that offers benefits without any downsides. It's as simple as that.
- pjmlp 12y ago
  C is dead on Windows and I hope Microsoft does not change its mind. C is almost dead on Android, with its minimal exposure on the NDK and I hope Google does not change its mind about it. C is now being killed on MacOS X and I look forward to Swift's success. So this leaves out the embedded industry (slowly moving to Ada and Java on IoT) and the hardcore UNIX guys.
  - robmccoll 12y ago
    Hahahah C is dead? Come on, don't start that kind of bating. High-level efficiency-oriented languages are high-level efficiency-oriented languages and low-level performance-oriented languages are low-level performance oriented languages. This has been true and will continue to be true. Notice the number of high-level languages that have waxed and waned while C has continued to flourish...
oldguysrule 12y ago
>Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. You can write shit code in any language - even Swift. >how about goto fail? I haven’t seen a goto in 20+ years. Strawman much? >C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents”. Yeah, and I suppose you’d prefer lumberjacks use rubber axes so they wouldn’t hurt themselves - or the trees for that matter. Life is dangerous. Get over it. >At some point we have to admit C is no longer acceptable. You bubble wrap your kids and lobby for lower jungle gyms at your kids schools too? Swift doesn’t solve these problems and you sound like a self righteous ninny. But hey - thats why there are scripting languages - for people who can’t deal with the machine. Pick one and go for it - but your scripting language isn’t suitably performant for things like audio processing (CoreAudio is in C/C++), real time control with tight tolerances, etc. Grow the fuck up. Sometimes you have to get your hands dirty and think hard and make stuff work. Your Swift code isn’t actually “safer” in the same way that the TSA hasn’t made flying safer - it is all security theater.
- dang 12y ago
  > you sound like a self righteous ninny [...] Grow the fuck up Personal attacks are not allowed on Hacker News. Please don't post anything like this.

pjmlp 12y ago

The sad part, is that already in the 70's there were better alternatives, but UNIX creators just decided to ignore them and create their own language.

feadog 12y ago
So they could implement SpaceWar on the PDP-11.

raould 12y ago

i registered just to say, "you're hired!"

wtracy 12y ago

It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. I'm looking forward to seeing your new operating system and managed runtime written entirely using garbage-collected languages!

sixbrx 12y ago
Parent poster didn't imply that the replacement would be garbage collected, just memory safe, which is a pretty big difference. I think you will see it sooner than you may think, it seems the tide may be turning.
- wtracy 12y ago
  Alright, I missed that nuance. I don't think I've ever worked with a language that provided memory safety without garbage collection.
kibwen 12y ago
I don't necessarily agree with the post you're replying to, but Rust is a memory-safe language without any garbage collection whatsoever. Proper unique pointers and move semantics are basically magic.
- mwcampbell 12y ago
  I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.
  - Pacabel 12y ago
    What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening. There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist. C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations. It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.

theseoafs 12y ago

> It is unethical to continue writing code in non-memory-safe C or C-based languages, for any purpose. Period. And since memory-safe languages are written in non-memory-safe languages (i.e. C and C++), writing code in them is unethical as well, right?

pjmlp 12y ago
Well, most implementations of Ada, Oberon and Modula-2 compilers among many others were boostraped, no C code in sight.

chillingeffect 12y ago

How about if you're developing in a field where the overhead of higher-level languages would prohibit the device from being made at all? Do you just put on your idealist hat and say, "Sorry! I can't develop a medical device for you. You'll just have to die. At least no one was required to be careful about their programming."

Pacabel 12y ago

So what other language can we use today on basically any imaginable platform, while still retaining the extreme degree of control, the excellent interoperability, and the near-optimal runtime performance of C? Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response. While there may be some validity to your claim about "billions of human beings wasting hours" due to vulnerabilities in C code, we can't forget that the alternatives would also suffer from significant forms of waste. If using a language with slower runtime performance, for example, people will need to wait longer for their computations to complete. More powerful, or even just more, hardware will be needed to alleviate these delays. Slower runtime performance also often results in much higher energy consumption. The costs just keep adding up and up. Forcing billions of people to use far less efficient software, while requiring far more powerful hardware, on a continual and ongoing basis, for decade upon decade, could very well generate waste that far, far exceeds that of dealing with an occasional flaw in widely-used C code. I just can't seriously buy your "All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes." argument. C won't be going anywhere until somebody provides a practical alternative that offers benefits without any downsides. It's as simple as that.

pjmlp 12y ago
C is dead on Windows and I hope Microsoft does not change its mind. C is almost dead on Android, with its minimal exposure on the NDK and I hope Google does not change its mind about it. C is now being killed on MacOS X and I look forward to Swift's success. So this leaves out the embedded industry (slowly moving to Ada and Java on IoT) and the hardcore UNIX guys.
- robmccoll 12y ago
  Hahahah C is dead? Come on, don't start that kind of bating. High-level efficiency-oriented languages are high-level efficiency-oriented languages and low-level performance-oriented languages are low-level performance oriented languages. This has been true and will continue to be true. Notice the number of high-level languages that have waxed and waned while C has continued to flourish...

oldguysrule 12y ago

>Heartbleed. Majority of all SSL keys on the internet compromised. All ~2 billion of humans on the internet required to change their passwords due to a single mistake by a single programmer using C. You can write shit code in any language - even Swift. >how about goto fail? I haven’t seen a goto in 20+ years. Strawman much? >C is like saying "forget seat belts, child seats, anti-lock breaks, and adaptive steering! How can I power-slide? I want full control; I need to pump the breaks. People should just drive better, then we'd have fewer accidents”. Yeah, and I suppose you’d prefer lumberjacks use rubber axes so they wouldn’t hurt themselves - or the trees for that matter. Life is dangerous. Get over it. >At some point we have to admit C is no longer acceptable. You bubble wrap your kids and lobby for lower jungle gyms at your kids schools too? Swift doesn’t solve these problems and you sound like a self righteous ninny. But hey - thats why there are scripting languages - for people who can’t deal with the machine. Pick one and go for it - but your scripting language isn’t suitably performant for things like audio processing (CoreAudio is in C/C++), real time control with tight tolerances, etc. Grow the fuck up. Sometimes you have to get your hands dirty and think hard and make stuff work. Your Swift code isn’t actually “safer” in the same way that the TSA hasn’t made flying safer - it is all security theater.

dang 12y ago
> you sound like a self righteous ninny [...] Grow the fuck up Personal attacks are not allowed on Hacker News. Please don't post anything like this.