3 ms·

Not that I agree with the upper comment, but functional languages that limit and rigorously encapsulate memory operations can eliminate a large number of these

Not that I agree with the upper comment, but functional languages that limit and rigorously encapsulate memory operations can eliminate a large number of these problems (the access itself is localized to monads, and the rest is strictly-typed and must be explicitly reasoned about). They can still be DDoS'd (too many open handles, out of memory, etc) to be sure. As long as there are fixed buffers, there will be buffer overflows but even using a functional style in C/C++ can often provide some of the same benefits (even just using const wherever possible...).

daeken 14y ago
I agree, but using functional languages won't let you replace C in the vast majority of cases. The performance hit is minimal, but the ability for code to be used from anywhere (as C libraries can be) is extremely important. Also, grouping C and C++ together in the context of security is a Bad Thing (TM). They have completely different security issues that plague them, and while C++ may be (mostly) a superset of C, it's truly a completely different language. Things like buffer overflows in string handling are next to nonexistent in proper C++ code, while they exist all over the place in C.
- vy8vWJlco 14y ago
  Yes and no. C and C++, as you note, permit a similar lowest-common-denominator programming style and so a similar class of low-level bugs. While the C++ libraries (std::string, etc) and other differences can help, they can be subverted through ignorance or will, and often are. The strict typing in C and C++ helps eliminate bugs over the same task written in assembly (or Forth, etc). In the same way, goto might best be used sparingly, since the sharper the tool, the more likely the damage done by accident. C and C++ sit at approximately the same "danger" level (potential for low-level access) whereas I think functional languages can be automatically "safer" (admittedly ill-defined), assuming you are willing to subjugate yourself to them and can trust the implementation (which is not always a fair assumption), since compilation boils down to a relational proof. (That's not to say it's my preferred style.) Furthermore, Haskell and OCaml, for example, can both be compiled to linkable objects (C interface-able), so I don't see the loss of interoperability as you suggest. A Haskell .o looks like any other.
- eru 14y ago
  > The performance hit is minimal, but the ability for code to be used from anywhere (as C libraries can be) is extremely important. I'd argue about the performance hit. (And I programme in Haskell for a living.) But FFI, on the other hand, isn't too unpleasant in functional languages.

daeken 14y ago

I agree, but using functional languages won't let you replace C in the vast majority of cases. The performance hit is minimal, but the ability for code to be used from anywhere (as C libraries can be) is extremely important. Also, grouping C and C++ together in the context of security is a Bad Thing (TM). They have completely different security issues that plague them, and while C++ may be (mostly) a superset of C, it's truly a completely different language. Things like buffer overflows in string handling are next to nonexistent in proper C++ code, while they exist all over the place in C.

vy8vWJlco 14y ago
Yes and no. C and C++, as you note, permit a similar lowest-common-denominator programming style and so a similar class of low-level bugs. While the C++ libraries (std::string, etc) and other differences can help, they can be subverted through ignorance or will, and often are. The strict typing in C and C++ helps eliminate bugs over the same task written in assembly (or Forth, etc). In the same way, goto might best be used sparingly, since the sharper the tool, the more likely the damage done by accident. C and C++ sit at approximately the same "danger" level (potential for low-level access) whereas I think functional languages can be automatically "safer" (admittedly ill-defined), assuming you are willing to subjugate yourself to them and can trust the implementation (which is not always a fair assumption), since compilation boils down to a relational proof. (That's not to say it's my preferred style.) Furthermore, Haskell and OCaml, for example, can both be compiled to linkable objects (C interface-able), so I don't see the loss of interoperability as you suggest. A Haskell .o looks like any other.
eru 14y ago
> The performance hit is minimal, but the ability for code to be used from anywhere (as C libraries can be) is extremely important. I'd argue about the performance hit. (And I programme in Haskell for a living.) But FFI, on the other hand, isn't too unpleasant in functional languages.