6 ms·

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take comple

by gens 9y ago

> Programs in the 90s were written in C and C++. C is impossible to secure. C++ is impossible to secure. Back then the compilers sucked. They would take complete crap of code and still it would work. They were like browsers are today. (from my experience from going through one old MUD code) Today the song is different. Not only will the compilers warn you of many things, there's even tools for static analysis (and dynamic). So the argument that C (and even the more complex C++) is inherently insecure holds much less weight (just go run old code through a static analyzer, or a normal compiler for that matter). That said there's only one way to write a "secure program", and that is formal verification. People that talk with a serious tone should back up their claims, at least that's my opinion.

jdietrich 9y ago
C and C++ simply weren't designed with safety in mind. Even with a good compiler and static analysis, security-critical bugs will slip through the net that simply wouldn't happen in other languages. It's not so much a question of whether it's possible to write safe C, but whether it's natural or easy. C is unsafe by default.
MikeHolman 9y ago
C and C++ are definitely not as secure as a language with automatic memory management. OOB reads/writes, type confusion, and UAF are all very real problems in C and C++. Static analysis helps, but it can't catch everything. I work on a modern C++ codebase, and we still face all of these issues. Formal verification is infeasible for most software projects, but they can get guaranteed type/memory safety by using a language proven to be safe. C/C++ can't give you that, but JavaScript might be able to.
- gens 9y ago
  Not as secure, but nowhere near the death traps as some(many?) describe them. Things that are written in C these days are usually written in C for performance reasons. FFMPEG would not have even close to the performance it has if it was written in a memory safe language instead of C and assembly. I doubt that a magical compiler (and/or language) will appear in my lifetime that can compile high level code into performant machine code, especially when it comes to memory management. (note that C also has advantages other then performance) JS doesn't even have a proper specification, let alone a bug-free interpreter/compiler. EDIT: AFAIK verifying memory access is part of a formal verification, where memory is also modeled mathematically.
Skunkleton 9y ago
People always shit on C for security, perhaps rightly so. But I would like to point out that 99% of everything out there has C or C++ at its base. cpython is c, java is C++, rust is based on llvm which is C++. Yes implementing your user facing application in some non-c language may improve security, but you are still depending on C when you do so. So is C the problem, or is it modern CPU architecture? C has stuck around for so long because of how close it is to assembly language. There will always be a need for a language that is one layer above assembly, and currently assembly is incredibly hard to secure.
- basicplus2 9y ago
  D
- pjmlp 9y ago
  Historicall baggage, during the 90's C and C++ were still two options among many, but like every market there is only a few products winning out. C is close to PDP-11 and 8/16 bit computer Assembly, it has hardly any direct mapping to modern CPUs.

by gens 9y ago

jdietrich 9y ago

C and C++ simply weren't designed with safety in mind. Even with a good compiler and static analysis, security-critical bugs will slip through the net that simply wouldn't happen in other languages. It's not so much a question of whether it's possible to write safe C, but whether it's natural or easy. C is unsafe by default.

MikeHolman 9y ago

C and C++ are definitely not as secure as a language with automatic memory management. OOB reads/writes, type confusion, and UAF are all very real problems in C and C++. Static analysis helps, but it can't catch everything. I work on a modern C++ codebase, and we still face all of these issues. Formal verification is infeasible for most software projects, but they can get guaranteed type/memory safety by using a language proven to be safe. C/C++ can't give you that, but JavaScript might be able to.

gens 9y ago
Not as secure, but nowhere near the death traps as some(many?) describe them. Things that are written in C these days are usually written in C for performance reasons. FFMPEG would not have even close to the performance it has if it was written in a memory safe language instead of C and assembly. I doubt that a magical compiler (and/or language) will appear in my lifetime that can compile high level code into performant machine code, especially when it comes to memory management. (note that C also has advantages other then performance) JS doesn't even have a proper specification, let alone a bug-free interpreter/compiler. EDIT: AFAIK verifying memory access is part of a formal verification, where memory is also modeled mathematically.

Skunkleton 9y ago

People always shit on C for security, perhaps rightly so. But I would like to point out that 99% of everything out there has C or C++ at its base. cpython is c, java is C++, rust is based on llvm which is C++. Yes implementing your user facing application in some non-c language may improve security, but you are still depending on C when you do so. So is C the problem, or is it modern CPU architecture? C has stuck around for so long because of how close it is to assembly language. There will always be a need for a language that is one layer above assembly, and currently assembly is incredibly hard to secure.

basicplus2 9y ago
D
pjmlp 9y ago
Historicall baggage, during the 90's C and C++ were still two options among many, but like every market there is only a few products winning out. C is close to PDP-11 and 8/16 bit computer Assembly, it has hardly any direct mapping to modern CPUs.