php: unsafe at any speed

Consider:

Looks pretty harmless? Yet this file demonstrates exactly why php should not be used with data you care about.

On the first line we divide a number by zero. Yes! And php will happily continue processing. We say division by zero is undefined in the true sense - you cannot define a result, any result, even an internal runtime tag denoting a undefined var. There is a warning on STDERR, but incredibly, php continues to run the script!
Next we compare the result of division by zero to another variable with ==, an operator so incredibly wrong that it should be removed from the language. This "soft" equality evaluates the "not set" value on the lhs with a newly-appearing variable on the rhs that has not been assigned any value. The (strange and broken) semantics of == allows these to evaluate to be equal (!!). And what does php say about the fact that $t on the rhs was never declared? No problem! php will gladly accept an unknown variable and gin up some state for it. If $t ends up just being a mis-type of another properly initialized variable we meant to use here, oh well! You'll never know until it is too late. php -l won't tell you anything, because technically, the introduction of $t here is not an error according to php (!!)
Finally we arrive at the place where I will be doing something to an important piece of data like your credit card number or your medical record. Yes, the code here is reached. It was reached after dividing a number by zero and then comparing that "result" to a variable that was never properly initialized!

Scary! Its scary that so much can go so wrong in just a few lines of code when using a poorly designed tool. I don't know of another language that allows something this unsafe to run. Even javascript, which is plagued with numerous historical type/value mistakes, won't run the equivalent logic.

It is truly frightening that users on the web have their valuable data handled by tools like this.

last update 2012-05-16