On the main PHP site there's a new announcement about a critical update in a new version to both the PHP 5.2.x and 5.3.x series of releases to correct a problem that could cause a hang or crash from user input - 5.3.5 and 5.2.17.

The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

On the SitePoint PHP blog today they pose a question to all PHP developers out there - is your application affected by the Y2K38 bug?

I don't want to be too alarmist, but try running the [given] PHP code on your system. [...] With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!

The bug, caused by a 32-bit operating system, can be helped by running the application on a 64-bit platform (it's due to the limitation of integer size), but there is another option - the DateTime class that handles dates and times differently than the just using the local time settings.

Chris Jones has a new post to his blog today showing how to use the latest 32-bit OCI8 (Oracle) drivers in a 64-bit Windows environment (like on Windows 7 or similar OSes).

The world migration from 32-bit to 64-bit operating systems is gaining pace. However I've seen a couple of customers having difficulty with the PHP OCI8 extension and Oracle DB on Windows 64-bit platforms. The errors vary depending how PHP is run. They may appear in the Apache or PHP log. [...] Other than IIS permission issues a common cause seems to be trying to use PHP with libraries from an Oracle 64-bit database on the same machine. There is currently no 64-bit version of PHP on http://php.net/ so there is a library mismatch.

The solution is to install the Oracle Instant Client, move a few files around, edit your path and you should be good to go.

Carson McDonald has just released a guide for getting the highly-anticipated release from Facebook, HipHop PHP, up and running on Fedora 12 systems (both 32 and 64 bit flavors).

The first thing to note is that they are only supporting 64 bit systems officially. [...] I'm going to assume at first that you are using a 64 bit system and then end with what you need if you are still using a 32 bit system.

He used an EC2 instance to substitute for a local 64 bit machine, but it works all the same. He includes the commands (package changes) to get the machine where it needs to be to perform the HipHop install and how to get the latest HipHop source from github. Most of the install is handled via packages, but you will need to get into the HipHop source a bit and change a few things for this issue. With everything in place you can run a cmake/make on the source and wait for the resulting binary to be created.

He's condensed down this whole process into one script for those that want a simpler solution.

In a recent post to his blog Tony Bibbs shares his experience with getting the most recent release (PHP 5.3 alpha) of PHP up and working on his MacBook.

If there is anything you should gleam from this article for future reference, Leopard comes with a 64bit Apache installation.

He points out this fact because, if you go and build it as per the normal install instructions, it will toss a "wrong architecture" error. He points out a blog post from Marc Liyanage that helped him understand a bit better. His fix was to run Apache as 32 bit instead of trying to get PHP to compile up to its 64 bit standards. He even includes the two commands you'll need to change Apache over to run this way.