Miloslav Trmač wrote: > The logical conclusion from this is to move to a language with automatic > memory management. The "top vulnerability" reports for programs written in > C/C++ and most other languages so different that starting a new project > that processes untrusted data in C/C++ is becoming indefensible. If by "automatic memory management" you mean garbage collection, then that's not really what we need. Garbage collection has advantages, but what is needed to stop the buffer overflows is bounds checking. The compiler needs to keep track of how big each object is and insert code to check that writes to an array stay within the bounds of the array. > Now, what to move to? I currently don't have see any language/runtime I > could recommend, which is in itself rather frightening. I recommend Ada. Ada does bounds checking, and is compiled to machine code with performance comparable to C. Only compiler bugs can cause buffer overflows in Ada, unless you're so foolhardy that you disable the bounds checking. Coding in Ada reduces not only security holes but also other bugs, because the language is designed to help the programmer avoid mistakes, and to allow the compiler to catch many mistakes as compile-time errors instead of run-time errors. Ada doesn't do garbage collection across the whole program, but features such as controlled types, generic data structures and out parameters greatly reduce the need for garbage collection. The double-free problem is also eliminated. (Garbage collection was made optional in Ada so that the language would be suitable for embedded real-time systems, and in practice most compilers don't provide it.) The disadvantage of Ada is a relative scarcity of libraries. That's not a problem with the language itself but a result of low popularity, and would change with time if more programmers would start using Ada. Help with packaging the libraries that do exist would be welcome. A free compiler? Yes, we have one in Fedora. Björn Persson
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel