Because we wouldn't want a function to accidentally process data that wasn't meant for it, no?
Don't think that you're escaping C or C++ just because you're using Ruby, or JavaScript, or Python, or Perl, or Tcl, or even Java. Don't think that you aren't as vulnerable using a dynamic language as you are using C or C++ directly.
Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities. There was one affecting Ruby and Ruby on Rails widely publicized just a few days ago. You can read more about it at: http://news.ycombinator.com/item?id=5002006
The whole idea that "Well it's insecure because you program in insecure way!" is outright idiotic, and should be killed. If that means getting rid of C and C++ and people who write in these languages(Hey, myself included!) then so be it. The faster the better. Sure, there are cases in which it's hardly possible, but I'd take 10 times slower computer for 1) fewer bugs 2) more advanced software 3) cheaper software 4) far less security concerns any day.
Now, I'm going to close the C++ project and go write some Python. Makes me feel happy and far less stressed, although C++ does damn well in comparison to C.
> There was one affecting Ruby and Ruby on Rails
What has it to do with Ruby, besides the fact that RoR is written in Ruby?Actually this is completely backwards.
Think exactly that you are NOT AS vulnerable as using C or C++ directly.
That it's C/C++ underneath has little importance.
It FAR MORE difficult and FAR LESS common to reach runtime/interpreter bugs that to produce bugs of your own in the higher level language.
>Furthermore, it is quite easy for dynamically typed languages to suffer from very serious security vulnerabilities.
Of a different kind, that doesn't pertain to the current discussion.
It's twenty goddamn thirteen, stop writing trivial buffer overflow vulnerabilities already. And that applies whether you are a novice or an expert.
In a statically typed language, where you already made the effort of using types, it would be a shame for your program to die or cause havoc because you didn't also think about enforcing some invariants.
Plus, those kind of errors in C can cause buffer overflows, privilege escalation and such.
In a dynamic language it's usually just a halt and a stack-trace.
(And actually there is a move to do exactly what you say --add type checks in dynamic languages. See Dash and Typescript, with their optional type annotations and checks. But if it was possible to optionally have those checks by pure inference, without adding anything to a dynamic language's syntax, most people would jump at it instantly).