6 ms·
> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.
by avian 11y ago
> It is time for the bimonthly Internet security meltdown.
Time for the bimonthly Hacker News hour of C and C++ hate.
- deleted 11y ago[deleted]
- pjmlp 11y agoYes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.
- cmrx64 11y ago(For the record, grandparent originally ended with "Some people just don't get it")
- deleted 11y ago[deleted]
- tosseraccount 11y agoWhat do you think?
- voidlogic 11y ago>Some people don't get it that before it happened we were happily using other systems programming languages way safer than C. Maybe some people, but most systems programming was done is Assembly before C.
- TeMPOraL 11y agoNo, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.
- bsder 11y agoWhose performance was so bad that porting the Lisp Machine software to a general purpose Alpha added multiple factors of performance increase.
- pjmlp 11y agoC compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly. And here we are now discussing how good modern C compilers are. If there isn't the willingness to spend the money to optimize performance, of course it won't improve.
- bsder 11y agoThe initial port of Genera to an Alpha matched the performance of Symbolics fastest workstations: http://pt.withy.org/publications/VLM.html http://pt.withy.org/publications/VLM.html "Version 1.0 of the emulator exceeded our initial performance goals, achieving nearly the performance of our high-end custom workstation." An initial port to a foreign architecture (in-order execution, 64-bit memory space which is going to overload caches, inefficient 8-bit transactions) matched 15+ years of hardware development on the native architecture. That wasn't lack of money or development. That was a stunning rebuke that Lisp Machines had an inferior architecture.
- pjmlp 11y ago> That wasn't lack of money or development. That was a stunning rebuke that Lisp Machines had an inferior architecture. No, it wasn't nothing more than lack of willingness and money to do it, instead they complained about the state of art and went home.
- bsder 11y ago> C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly. For good reason: memory and disk were ferociously expensive until about 1996-1997. Things like unchecked bounds make sense when you can barely get your computer to do what you want. Designing a VLSI chip through about most of the 1990's was HARD. Everything was an exercise in how to fit things on disk, fir things in RAM, run enough polygons, or run enough instructions on the emulator to actually boot. Now: we can emulate a 6502 in Javascript while animating it. We can emulate entire PowerPC chips at real-time speed. So, yeah, NOW allocating a couple of cycles to bounds checking and garbage collection makes perfect sense. We should have started the conversion away from C in 2000. The problem is that 1) sunk cost keeps design decisions made in vastly different environments around for far longer than is reasonable and 2) we didn't really have good replacement options for C until starting about 2005. And then the cellular phone revolution hit and put us back to programming like its 1995. Finally, now that cell phones even have an overabundance of CPU, storage, and memory--we now can start to care about security.
- pjmlp 11y agoIf targeting home computers, the so called mini-computers and home micros, yes. C was just yet another "managed language". If targeting real computers, what is nowadays left as mainframes, then no. Extended Algol was already being used by Burroughs in 1961 for writing Assembly free OSes. There are lots of other examples, which C advocates tend to ignore, so that they can sell the story that before C there was only Assembly to those that don't bother with history of computing.
- TeMPOraL 11y agoIn general, adoption of UNIX has managed to convince a lot of smart people to believe something as absurdly sounding as "worse is better". (I'm only half-sarcastic here.)
- blt 11y agoAnyone who reads HN for long enough knows, thanks to your comments ;)
- TazeTSchnitzel 11y agoWhich is quite justified, as with more modern programming languages, these sorts of bugs are much less likely to happen.
- Mikushi 11y agoAre they? We have no way to know as no modern language has the reach and widespread usage of something like C. As much as I'd like to think Rust is a nice option for the future, everything leads me to believe that if it ever gets as widespread as C you will have the same caveats, because the main issue is not the language but the programmers using it. No amount of hand holding and safety will prevent bad practices from being used when they prove efficient in one way or another (laziness is a real killer).
- TazeTSchnitzel 11y ago> Are they? Yes, they are. > We have no way to know as no modern language has the reach and widespread usage of something like C. None needs to have that widespread usage for us to see this. Many bugs in C code causing big security issues are impossible to make in more modern programming languages. Sure, you can make other security issues, of course you can. But the net result is less security issues. > the main issue is not the language but the programmers using it. All bugs are caused by programmers making mistakes, but that doesn't mean the language isn't an issue. A language which requires more effort to write correct and secure programs is an inferior language. A language with a long list of situations where the compiler will silently invoke unpredictable behaviour, a list any programmer will sometimes fail to fully account for, is an inferior language.