One of the things the C++ experts take particular care to remind everyone is that character arrays are evil. I thought using string classes mostly elminated the buffer overflow problem. The string class is heavily examined for such errors as are the intrepreters.
I'm seeing reports of vulnerabilities in interpreted languages so I'm not sure I agree with that logic, or the orders of magnitude comparison. Do you have any references or research on it?
Interpreter authors write code with errors too. If the interpreter gets tweaked every month the code only gets 30 days of testing. Few of the packages I've seen have any regression testing so new errors can be introduced with each revision and old errors can reappear.
I should go look and see how they cracked php and string overflows.
I say "orders of magnitude" if a class of errors is the one that occurs the most frequently, and only appears with the compiled languages. By emiminating the most common problems, orders of magnitude improvement is gained.
With interpreters, any buffer overflows etc are only in the interpreter itself, and can never be in your own code written in the interpreted language. Usually, the amount of code in the interpreter is many orders of magnitude smaller than the amount of code that is written in the interpreted language. With C/C++ code, the entire code base can be suspect, but in an interpreted language, only the tiny fraction of the code making up the interpreter itself is suspect. When the code base that can have such problems is a lot smaller, the total number of actual problems is smaller.
The greater part of my experience with interpreted languages is with Perl 5.8, which is used by tens or hundreds of thousands of programmers regularly, and whose source code is scrutinized and worked on by probably several dozens of people each day. Perl 5.8 also has a large and comprehensive unit test suite, including regression tests. It is very hard for bugs to get by it. Let me know if you're aware of any security vulnerabilities with Perl 5.8. The Parrot project also has strong regression testing, though that project is pre-alpha.
As for PHP, well I consider that specifically to be less elegant than many other interpreted languages, and much more likely to be buggy. This has a lot to do with its ad-hoc design principle, just throwing in features wherever, rather than having a more thought out system design.
All of the above being said, you do gain a lot of the same advantages of interpreted languages in C/C++ in regards to bugs and security when you use a library that is already well written to handle common tasks, as some other posters here mentioned. In that respect, the interpreted language is alike, since you are implicitly using libraries rather than explicitly.
-- Darren Duncan
