Slashdot Mirror

It seems that the bug was in the code base for at ~10 days before someone (external) discovered it. That does not seem to be (just) a case of unit tests being skipped in a rush, it seems like a surprising lack of automated testing.

The PHP project has shown some pretty poor QA when it comes to defects in their code.

Hell, their ODBC interface has been returning wrongly typed data for years now and nobody on the project seems to care. It's not like ODBC is something brand new and still widely misunderstood.

It's almost like the people who build PHP aren't even interested in maintaining it.

From the Bug report:

> Confirming, some very recent update broke it - right now unit tests fail on SVN. I wonder if nobody run it before release?

So they do have a unit test for that. They just didn't run it before release :).

This bug has been fixed already. See https://bugs.php.net/bug.php?id=55439
Main problem was if an aplication stores its hashes in a database and use them as authentication then:
$valid = crypt($pw, $crypt);
will always be TRUE regardless of $pw
For all this, PHP Team said it is fixed in SVN and recomending to wait (upgrade) till 5.3.8

Many common escape routines will be helpless if you're writing directly into JSON for use by JSON.parse (much less eval).

Who would generate JSON in PHP without using json_encode()?

As a php code monkey and not a certified DB engineer, I will admit a certain level of ignorance on the issue... however:

I am dumbfounded by the claim that they have an application that is stuck on one db and it is because of the code that runs the site. I have never, ever worked on a credible project that was not data-base agnostic. Many, many excellent tools exist for abstracting the DB out of your code entirely, many of them are part of newer php releases itself or as part of pear.

To be honest, if they are so tied to MySQL, that probably means that their code is a horrid nightmare that needs a complete re-write anyway, and there is no way to blame that kind of crappyness on MySQL. If, in the YEARS that they have been popular and getting more popular, they have not been doing incremental changes to move to one of these systems, that speaks very poorly of their development management. Hell, it probably means that their code is so bad that with a good rewrite they could stick with MySQL for a number of years to come.

As a php code monkey and not a certified DB engineer, I will admit a certain level of ignorance on the issue... however:

I am dumbfounded by the claim that they have an application that is stuck on one db and it is because of the code that runs the site. I have never, ever worked on a credible project that was not data-base agnostic. Many, many excellent tools exist for abstracting the DB out of your code entirely, many of them are part of newer php releases itself or as part of pear.

To be honest, if they are so tied to MySQL, that probably means that their code is a horrid nightmare that needs a complete re-write anyway, and there is no way to blame that kind of crappyness on MySQL. If, in the YEARS that they have been popular and getting more popular, they have not been doing incremental changes to move to one of these systems, that speaks very poorly of their development management. Hell, it probably means that their code is so bad that with a good rewrite they could stick with MySQL for a number of years to come.

# Bind result columns with $sth->bind_col

I don't see any method called bind_col() in the left column of this page. All I see are bind_param() and bind_result(), both of which use a variable number of arguments passed by reference to the method rather than taking an array as an argument.

I think a greater consideration is the purpose of the error page. If your purpose is to entertain someone who is trying to get to your content but not quite finding it, then that's fine, but you should consider whether your purpose ought to be helping the user find the content. Imagine a public library whose entrance is hidden behind a tree on the back of the building. Should the street-facing side of the library strictly keep people smiling until they give up on entering the library? It can certainly be designed to bring a smile to the would-be patron's face, but the primary goal is to help him drop the "would-be" from his moniker and enter the library to find the world of knowledge within. A good 404 error page does entertain, but not at the expense of helping the user find what he is actually looking for.

Here are some examples that are helpful: Apple points you to the search box and gives a top-down view of the site to help you find the desired content, while PHP directs you to a search for the URI path in the PHP manual.

Few, if any, of the thirty 404 pages in the FlashUser article are helpful. They are all at least somewhat creative and fun, but when it comes to advising web designers they are not particularly good examples of helping the user out.

He specifically refers to the alternative syntax for PHP, which is stuff like:

if ($a == 1):
...
endif;

i.e. a colon instead of the opening curly brace, and a keyword instead of the closing brace. This makes sense for PHP templates, because it can be hard to figure out what a standalone "}" after half a page of HTML refers to. But I think it's rather arguable whether it is more readable than braces when it's all just code.

Turn register globals off in PHP. Use safe mode.

Yes on the first, be aware on the second. It's been deprecated, as noted at http://php.net/manual/en/features.safe-mode.php Safe mode is really a band-aid on an open wound. mod_security, suhosin, proper file ACLs, etc. are all likely better options for dealing with the sorts of things safe_mode buys you, and all but suhosin are applicable to anything that isn't PHP.

Aside from that, a good list. The one thing that can't be said enough: NEVER TRUST CLIENT INPUT. VERIFY, VERIFY, VERIFY.

NONE of them are doing what I want, where you type the name of a file and it selects what to run.

Sigh, no, you really don't know what you're talking about. example for windows - Linux stuff on Wiikipedia

You are correct sir....

in php....

$new_string = preg_replace(“/[^a-zA-Z0-9\s]/”, “”, $string);

or simply use the http://docs.php.net/manual/en/function.mysql-real-escape-string.php function if you need full flexibility and to make sure it's clean and safe.

and done. in fact you are a lazy programmer if you dont sanitize your user input. Yes it's nice to add the extra security of setting up the DB correctly, but only a fool would not sanitize the user input to begin with.
Rule #1 is to treat all user input as hostile and dangerous. If you stick to that a lot of these pesky injection attacks go away.

Not to be a dick, but mysql.com is written in php and you cannot bind variables in php (based on a simple google search).

Are you sure you actually fired up a Google search? The second result of a search for "php mysql bind variables" leads you directly to this function. Not to mention ADOdb can fake it even if you don't use the mysqli driver, and I'd bet PDO and the other libraries can do the same. Seriously, even if you're a PHP developer (I'm one), you have NO EXCUSES for not using bind variables. The hassle is quite low, and the peace of mind is priceless...

OMG!

It looks like PHP.Net has taken over the entire PHP project. Just look at the URL!!

If only php had such an interface...

Oh, wait, I'm sorry, were you talking out of your uninformed ass to bag a "beginner" language that everybody here thinks that they are above and whore some karma points? Well, carry on then.

I guess I made a "hash" of making my point.

Case study:, people trying to increase security be doing odd things such as first hashing with SHA1, then MD5, and many, many strange combinations. None of which actually improve security.
Not even security though obscurity, but obscurity though spaghettification.

Bottom line: Stop torturing that weak hash algorithm. Feed a strong key into a strong hash.

Search http://us3.php.net/ [php.net] for 2.2250738585072011e-308 and the page hangs and then returns an error. Search for something else like 2.2250738585072011e-307 and it's fine.

Maybe because the target number is slashdotted?
   

mb_internal_encoding('UTF-8');

Fatal error: mb_internal_encoding is not defined because mbstring is not enabled by default. And no, you can't install this extension on your hosting company's copy of PHP.

In typical PHP fashion, the patch doesn't actually fix the underlying problem, it simply checks for that one specific string. Seriously, stop gloating for 30 seconds, check the source and cringe at the incompetence.

What are you talking about? There is more than one number that triggers the problem, and the patch does not do a simple string comparison.

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=304407&r2=307095&pathrev=307095

I don't understand why the patch solves the problem....though I haven't done any serious software development for years. It looks like all they did was add the "volatile" keyword to a variable declaration.

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_strtod.c?r1=307095&r2=307094&pathrev=307095

From:

double aadj, aadj1, adj;

To:

volatile double aadj, aadj1, adj;

But after quickly reviewing the code, I don't see why the volatile keyword fixes this problem. It doesn't appear to be multithreaded code where another thread could stomp on the variable, and it just seems to be straight arithmetic, it doesn't seem like they are handing it off to a math coprocessor and then later waiting for the variable to be set.

Does the volatile keyword change the compiler optimizations in a way that avoids the problem?

I looked. Seems they fixed it: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_strtod.c?r1=307095&r2=307094&pathrev=307095

Crypt isn't that flawed and ancient. It can also do blowfish, SHA512, and SHA256. You can also force a number of rounds too, to make hashing much more time consuming.

http://php.net/manual/en/function.crypt.php

Here is example code & output copied from that link:
if (CRYPT_SHA512 == 1) {
        echo 'SHA-512: ' . crypt('rasmuslerdorf', '$6$rounds=5000$usesomesillystringforsalt$') . "\n"; ...
Standard DES: rl.3StKT.4T8M
Extended DES: _J9..rasmBYk8r9AiWNc
MD5: $1$rasmusle$rISCgZzpwk3UhDidwXvin0
Blowfish: $2a$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi
SHA-256: $5$rounds=5000$usesomesillystri$KqJWpanXZHKq2BOB43TSaYhEWsQ1Lr5QNyPCDH/Tp.6
SHA-512: $6$rounds=5000$usesomesillystri$D4IrlXatmP7rx3P3InaxBeoomnAihCKRVQP22JZ6EY47Wc6BkroIuUUBOov1i.S5KPgErtP/EN5mcO.ChWQW21

that new Facebook features are written simply by some kind of weird combination of /dev/random and http://www.php.net/manual/en/ with the noise being supplied by a 1000 monkeys?

Please somebody mod my original post as Funny and not Informative to avoid future PHP-Nukes.

What you actually need to do at the very least is:

1. md5 (or another algo) with Javascript on the client and compare that hash to the one saved in the DB. If the password is stored in cleartext (which it shouldn't be, but sometimes external systems are out of your control), md5 it with PHP.

2. Some people use SSL on the login page.

3. But this attack shows crackers just intercepting an replaying the creds. Discouraging that might involve IP or other checks. Defeating it might involve total encryption.

Variable variables..., 'nuff said.

That thing should have been shot at birth...

I worked on a project several years ago that had a lot of statistical calculations (standard deviation, correlation, distributions, etc.) and was surprised to find that PHP doesn't offer these functions so I had to write my own PHP code to calculate this stuff. I was thinking that implementing an optimized library of various commonly used stats functions would be something that might fit your skill set well. PHP is written in C (and possibly some C++ but I'm not sure). I am re-learning my long lost C chops at the moment in order to contribute to AMFEXT:
http://pecl.php.net/package/amfext

AMFEXT is an extension to PHP and can either be compiled into the PHP executable itself or compiled as a shared object -- a separate file. This extension structure makes it pretty easy to expand PHP because your extension is entirely optional for folks building PHP so it would not be critical to write perfect code right away. In order to get started developing such an extension, there are a variety of tricks to get oriented.

One is to read the pecl-dev mailing list:
http://news.php.net/php.pecl.dev

Another is to read some tutorials. This one is pretty good:
http://devzone.zend.com/article/1021

Here's a quick start guide describing how to make your own 'hello world' extension:
http://blog.slickedit.com/2007/09/creating-a-php-5-extension-with-visual-c-2005/

You don't need permission to download the source and compile it yourself and start building your own extension. If you want it to be included in the PECL repository, you just have to join the mailing list and submit your extension for the other contributors to see. They'll let you know what further steps to take.

I could also use some help with my open source project:
http://flashmog.net/

I worked on a project several years ago that had a lot of statistical calculations (standard deviation, correlation, distributions, etc.) and was surprised to find that PHP doesn't offer these functions so I had to write my own PHP code to calculate this stuff. I was thinking that implementing an optimized library of various commonly used stats functions would be something that might fit your skill set well. PHP is written in C (and possibly some C++ but I'm not sure). I am re-learning my long lost C chops at the moment in order to contribute to AMFEXT:
http://pecl.php.net/package/amfext

AMFEXT is an extension to PHP and can either be compiled into the PHP executable itself or compiled as a shared object -- a separate file. This extension structure makes it pretty easy to expand PHP because your extension is entirely optional for folks building PHP so it would not be critical to write perfect code right away. In order to get started developing such an extension, there are a variety of tricks to get oriented.

One is to read the pecl-dev mailing list:
http://news.php.net/php.pecl.dev

Another is to read some tutorials. This one is pretty good:
http://devzone.zend.com/article/1021

Here's a quick start guide describing how to make your own 'hello world' extension:
http://blog.slickedit.com/2007/09/creating-a-php-5-extension-with-visual-c-2005/

You don't need permission to download the source and compile it yourself and start building your own extension. If you want it to be included in the PECL repository, you just have to join the mailing list and submit your extension for the other contributors to see. They'll let you know what further steps to take.

I could also use some help with my open source project:
http://flashmog.net/

The way I did it:

To learn Java: http://download.oracle.com/javase/tutorial/reallybigindex.html
To learn PHP: http://www.php.net/manual/en/ (start with the simple tutorial)
To learn Perl: SAMS Teach Yourself Perl in 21 days, http://www.amazon.com/Sams-Teach-Yourself-Perl-Days/dp/0672320355/ref=sr_1_1?ie=UTF8&s=books&qid=1280710004&sr=8-1

I don't recall where/how I learned HTML/CSS. w3schools.com might have helped--it certainly helped with Javascript--but beware, particularly with Javascript, that not everything there is portable or even right. Once you have the feel for HTML and CSS, just go to w3.org where the specs are fairly readable.

• x86 Assembly
• The C Programming Language by Brian Kernighan and Dennis Ritchie
• TCP/IP Illustrated Volume 1: The Protocols by W. Richard Stevens
• PHP.net

MySQL 5's Fulltext index with the "natural language search" option might do everything you need with almost no overhead. That, plus PHP's PDO to connect to the database, and I think you might be done. How much data are we talking, anyhow? 10,000 magazine articles or less?

Subtle dig at PHP?

You know PHP does offer nice ways to do this, along with many horrible ways along with ACs all too commonly used example.
PDO::prepare for example.

Here are a few pointers, mostly around PHP web app security:

- http://www.owasp.org/ - the Open Web Application Security Project has a comprehensive list of things to cover - see their http://www.owasp.org/index.php/PHP_Top_5 (top 5 PHP issues) in particular

- http://www.sitepoint.com/article/php-security-blunders/ Top 7 PHP security blunders - use =htmlspecialchars= for output of variables to page and do MySQL string escaping

- http://www.phpbuilder.com/columns/ian_gilfillan20050707.php3 - ensure include files can't be reached directly from HTTP.

- http://it.slashdot.org/comments.pl?sid=1121901&cid=26797895 - use http://us2.php.net/manual/en/function.filter-var.php -PHP Filter features]] (only in PHP 5.2.0 onwards)

- http://sucuri.net/ - monitors your site for free to detect compromises that affect readable pages

Final point: don't "filter out" dangerous characters, this is never ending and can never be done - instead, for any given parameter or input field, define the valid characters (e.g. alphanumeric, date, etc) and specifically allow ONLY those characters. This 'filtering in' approach is far safer.

/greger

Wasn't rsync atomic operation, while - for example - cp wasn't? I can't find source to confirm this and all I have is this http://pl.php.net/manual/en/apc.configuration.php#ini.apc.file-update-protection entry in PHP manual, so...

It's a convoluted horrendous mess that requires five times as much code

But are search functions always (needle,haystack), or are half of them haystack first?

This is a huge annoyance for sure. Having coded in all the above mentioned languages, I can definitely say that when I look at explode, stristr, str_replace, etc in PHP, their lack of consistency bugs the hell out of me, but it's easy to work around.

http://www.php.net/ and now I know. Do that a few times and I'll remember.

Changes in PHP 6
Issue: Register globals are the source of many application's security problems and cause a constant grief.

Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.

Conclusions:

We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting

http://www.php.net/~derick/meeting-notes.html#id12

Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.

Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.

Conclusions:

We remove the magic_quotes feature from PHP.
We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.

http://www.php.net/~derick/meeting-notes.html#id13

They are also planning on getting rid of the non-PDO db stuff at a future date.

Changes in PHP 6
Issue: Register globals are the source of many application's security problems and cause a constant grief.

Discussion: We shortly discussed how we want to attend users on the disappearance of this functionality. We decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and some introduction on safe programming.

Conclusions:

We are going to remove the functionality.
We throw an E_CORE_ERROR when starting PHP and when we detect the register_globals setting

http://www.php.net/~derick/meeting-notes.html#id12

Issue: Magic_quotes can be cumbersome for application developers as it is a setting that can be set to on or off without any influence from within the script itself as input parameters are escaped before the script starts.

Discussion: In the same way as with the remove of the register_globals functionality, we decided that if we find the setting during the startup of PHP we raise an E_CORE_ERROR which will prevent the server from starting with a message that points to the documentation. The documentation should explain why this functionality was removed, and point the users at the input_filter extension as replacement.

Conclusions:

We remove the magic_quotes feature from PHP.
We throw an E_CORE_ERROR when starting PHP and when we detect the magic_quotes, magic_quotes_sybase or magic_quotes_gpc setting.

http://www.php.net/~derick/meeting-notes.html#id13

They are also planning on getting rid of the non-PDO db stuff at a future date.

you are exaggerating.

PHP has 5718 functions in the main namespace. Python has 79. Which is easier to learn and less likely to cause collisions?

So find a web host and get working. You can do that with some _very_ simple PHP - I have. I have a site that pulls news posts off of a facebook group and reformats them and such. It's about 10 lines of code. I also have an even smaller script that just pulls a specific text block off another page. And one that reads from an RSS feed. It's really not that hard.

http://php.net/manual/en/function.fopen.php

Sometimes I wished `break` could take argument of how many levels it should break out of

It can in PHP. Java and Perl have a different solution: label the start of a loop and then use that label as the argument of break. In C, it's just a matter of discipline to use goto only to replace a throw or labeled break.

Sorry apparently my brain decided to go mushy on me, the system I was thinking of was PDO (what an unfortunate name), linky: http://www.php.net/manual/en/book.pdo.php

Add this.

"NOTE: This software has reached it's end of life and will no longer be supported."

If you want to tidy up one last time.

Assuming MySQL, use "mysql_real_escape_string" (PHP 4 >= 4.3.0, PHP 5) takes into account the character set of the connection.

http://us2.php.net/manual/en/function.mysql-real-escape-string.php

Then something like:
// Reverse magic_quotes_gpc/magic_quotes_sybase effects on those vars if ON.

if ( get_magic_quotes_gpc() )

{

        $product_name = stripslashes($_POST['product_name']);

        $product_description = stripslashes($_POST['product_description']);

} else {

        $product_name = $_POST['product_name'];

        $product_description = $_POST['product_description'];

}

// Make a safe query
// %s - cast the input to string
// %d - cast the input to base 10 int

$query = sprintf("INSERT INTO products (`name`, `description`, `user_id`) VALUES ('%s', '%s', '%d')",

                  mysql_real_escape_string($product_name, $link),

                  mysql_real_escape_string($product_description, $link),

                  $_POST['user_id'] );

Certain software (Firefox, Sun's Java, Flash Codec, PHP, GCC, the linux kernel itself) should always be the latest stable version available from the main source itself. Yet Ubuntu lags behind by six to twelve months? All this talk of checking for stability etc is nonsense, since how much code do Ubuntu people actually read (or can even modify) in Firefox, PHP or Sun's Java codec? Just give us users the option to upgrade to the latest stable version within 24 hours it is made available. Let us decide which version we want to run. This is one of those rare things Windows does right, Ubuntu should not be ashamed to copy the right ideas no matter where they come from. These software are commonly used for web development and browsing, so there are clear security and performance benefits by using the latest versions.

I do not want to use Java 6.0.15 when I know Sun has made the 6.0.18 available on their website. I do not want to run Firefox 3.5 when I know Firefox 3.6 is so much faster. I do not want to run PHP 5.2 when the PHP changelog demonstrates anyone not using the latest stable version is an idiot. I do not want to rely on some random, untrusted person's "PPA". Nor do I want to download the source and compile. No, I do not want to wait for six months for next Ubuntu version either; six months is ages when security and performance are concerned.

Matt, are you going to change the culture of laziness and start giving us latest version of commonly used software (preferably within 24 hours of release)? I just want to be able to stay in GUI, run the Upgrade Manager and get the latest stable releases. Please, I beg you, is this too much to ask for? Because otherwise Ubuntu is the perfect Linux distribution for me.

I agree with you on Perl being as full of crap as PHP (especially the $%@-ing variables). The problem is that you have to consciously work around PHP's piles of crap constantly to do even simple things.

I'll give you an example:

my @array = list_returning_function() or qw(default values);
 
sub crash_and_burn {
    @_ or throw 'up';
    say $_ foreach @_;
}
 
exec {
    crash_and_burn(@array, 'some other value');
};
if ($@) {
    error_handler($@);
}

And then in the other corner...

<?php
$array = array_returning_function();
if ( !$array ) {
/* if you're lucky enough to have php 5.3, you could use "?:" in place of perl's "or" */
    $array = array('default', 'values');
}
 
function die_in_a_fire(array $array = null) {
    if ( is_null($array) ) {
        throw new Exception('wuh');
    }
 
    $stuff = $array;
    if ( func_num_args() > 1 ) {
/* If you try to use the output of func_get_args directly, you get a fatal error. Seriously. */
        $tmp = func_get_args();
        array_shift($tmp);
        $stuff = array_combine($stuff, $tmp);
    }
    foreach ( $stuff as $i )
        echo $i, "\n";
}
 
try {
    die_in_a_fire($array, 'something else');
}
catch (Exception $e) {
    error_stuff($e->getMessage());
}
?>

And that's just a basic syntax example.

Also I should point out PHP's @ can be used in a useful way like Perl's exec/$@ (I don't think the similarity between them is a coincidence), but 99% of the time that's not what happens.

There is a cyclic reference GC in PHP 5.3, but apparently not enabled by default
http://php.net/gc_enable

Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).

The SPL in PHP 5.2 and 5.3 adds a few new datastructures to help improve that (benchmark).

and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?

It should be clearly obvious that if you want to use a string as an integer, you use intval to convert it first. Programmers who know the difference between strings and integers know that. Don't take that personally, that comment isn't aimed at you, there are many, many PHP "programmers" who really don't know anything about data types (as a question answerer on the w3schools forum, I can readily attest to this; the level of inexperience people have when trying to tackle major projects is staggering).

It's difficult to fault a language just because it's easy to learn though. PHP is easy to learn, because it does a lot of stuff automatically (casting, error suppression, etc, like you said). So that means a lot of people copy and paste, go through quick tutorials, etc, and try to write code in it. You end up with a lot of crappy code, but that's not the fault of PHP, that's the fault of the people who are trying to write code without learning any theory at all (literally). Any decent programmer would be pretty surprised that a large portion of people asking PHP questions on w3schools are developing on a server with error message display disabled, errors are routed to a log file instead. They don't know that, and don't know how to change it, so they never even see error messages, just a blank page when they get a fatal error. I sometimes wonder how those people ever manage to debug, then remember that's why they're posting on the w3schools forum.

Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block

C'mon, if you want to cherry pick examples you can claim whatever you want.

The error suppression operator is for suppressing errors. The die/exit statements are for quitting execution and optionally printing a message. Some functions return false if they fail, so you can do something like this:

mysql_query($sql) or exit(mysql_error());

to print a specific error message for a specific situation. It should be obvious that's equivalent to this:

if (!mysql_query($sql)) exit(mysql_error());

That's what your example shows, printing an error that a file couldn't be opened if the file wasn't able to be opened. If you want exception handling and try/catch blocks, here you go:

http://www.php.net/manual/en/language.exceptions.php

Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!

Oh, good lord. I didn't know about that one. Every time I think I know just how awful PHP is, I learn something like that.

I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.

I think it is a bit like penis envy. Not all of them, but a lot of PHP monkeys like to think imagine they're much more hard-core than they are, so they compare what they do to what they perceive as a "real" language.

If they took the time to actually understand what makes Perl, Python or Ruby so superior, well, it is unlikely that they'd still be happy with PHP.

As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug.

PHP is not a simple language. A keymark of a simple language is consistency, and PHP is anything but - I won't even touch on the mess that is the standard function library, but just the language itself. For example, this gem, taken directly from the language spec, regarding array indices/keys:

A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). Floats in key are truncated to integer. The indexed and associative array types are the same type in PHP, which can both contain integer and string indices.

This is awesome on many levels. The obvious fubar is the treatment of "8" vs "08" (and note that, while it is clearly obvious when a string literal is used in the source code, how about a string variable, or other expression computed at runtime?). But the bit about silent float->int truncation is also interesting, especially the "silent" part. Combined with rounding errors and the overall non-obviousness of binary floating-point arithmetic (especially to a typical PHP coder), this design decision is just hilarious.

I've long held the opinion that C/C++ rules on mixed signed/unsigned arithmetic and comparisons are a good example of awful language design, but PHP beats that by a margin so large it's not even funny.

Oh, I also don't know of any other language that has what effectively amounts to synactic sugar for try/catch with an empty catch block. Good programming practices FTW!

I find it curious, by the way, that PHP coders like to compare the language to C++ or Java - where it actually has some subjective advantages, such as dynamic typing - but very rarely to Perl, Python or Ruby, where all such advantages disappear, but design flaws immediately stand out.