Anti Veeranna

I found the following gem over at Stackoverflow.com today. Given the following code, what do you think the result is?

<?php
var_dump("01a4" == "001a4");
var_dump("01e4" == "001e4");

The correct answer is:
bool(false)
bool(true)

Why?

PHP doesn’t like strings. It’s looking for any excuse it can find to treat your values as numbers. Change the hexadecimal characters in those strings slightly and suddenly PHP decides that these aren’t strings any more, they are numbers in scientific notation (PHP doesn’t care that you used quotes) and they are equivalent because leading zeros are ignored for numbers. To reinforce this point you will find that PHP also evaluates “01e4″ == “10000″ as true because these are numbers with equivalent values.

Previously.

Lets suppose you are learning to build PEAR packages (Pirum is a very nice PEAR channel server btw). You managed to create and publish the initial version of the package and it even installed just fine after you ‘pear install’-ed it.

Then you fixed a bug in the source, increased the version number in package.xml, built and published the next version. The new version is listed at the Pirum generated page.

• But ‘pear upgrade channel/Package’ does not ugprade to newest version.
• Forcing upgrade with -f does not help either.
• Uninstalling and reinstalling the package still gets the previous version.
• channel-update does not help.
• After uninstalling the package, removing the source from Pirum, regenerating the index and trying to reinstall you get a nice error stating that this version does not exist at the server.

I was really puzzled by all that. Then I discovered the reason – by looking at pear configuration.

$ pear config-get cache_ttl
3600

Channel contents are cached for that many seconds (3600 = 1 hour). The solution is to either reduce this number, or – preferrably – nuke the cache by

$ pear cache-clear

After this your package will upgrade just fine ;)

Its very logical to cache this information of course to avoid killing package servers and I feel really stupid for not figuring it out earlier.

I have had to deal with Soap lately. Mostly it works, except when it doesn’t. In my case I found out that its not exactly straightforward to make a Nusoap client talk to a PHP5 Soap server. Of course, it also depends on the WSDL. Probably. Maybe. In any case I was in a world of pain, which I do really not want to describe in more detail.

But then I found this article, and it made my day :) S stands for Simple. I have been suspecting this, but now its proven. Sigh.

Let me sum up. The definition of SOAP is in constant flux, SOAP is anything but simple, and it is no longer meant for accessing objects-even though that’s what all the tools still do.

Giorgio Sironi compiled a really nice e-book explaining practical PHP testing with PHPUnit. You can download the book from his site.

Given the following piece of PHP code:

$a = '1112000000001779149';
$b = '1112000000001779148';
var_dump($a == $b);

Can you tell, without trying to run it, what the result is?

The answer – it depends on your platform. On a 64bit platform you will get boolean false, on a 32bit platform you will get boolean true.

Why? Because PHP does type juggling, if strings are compared and they look like numbers, then they will be convereted to numbers before doing the comparision. And the following piece of code demonstrates the behaviour:

print php_uname('m');
print "\n";
print PHP_INT_SIZE;
print "\n";
print (int)1112000000001779149;
print "\n";

If you run it on different platforms, then this is the result that you will get:

x86_64
8
1112000000001779149

i386
4
-1

From this its already obvious, why the above string comparision resulted in true on 32bit platform. Its because -1 indeed equals -1.

Solution?

Either use === for comparisions, or if you care about your numbers, use the bcmath extension