Reputation: 925
I have a problem with PHP. I've built an application which connects to an Oracle DB, fetch some data, and sometimes make some comparisions.
The problems is that the Oracle data uses really large integer Ids (21 characters long). I try to use this Ids as strings, but when I try to compare this strings I get different results, depending if I'm working on the production server (Ubuntu 12.04 with PHP 5.3.10) or on the development machine (Ubuntu 14.04 with PHP 5.5.9).
This is one of the functions that doesn't work correctly:
public function isSomeUser($userId) {
$blacklist = array(
'102300000000000000693',
'102300000000000001194',
'102300000000000001593',
'102300000000000001994',
'102300000000000001996',
'102300000000000002395',
'102300000000000001998',
'102300000000000002496',
'102300000000000002097',
'102300000000000002490',
'102300000000000002493',
);
return (in_array($userId, $blacklist));
}
On the dev machine, if I call isSomeUser('102300000000000009999'), the returned value is false (the element doesn't exist in the array), but on the production machine, the returned value is always true. I can fix this behavior adding a last parameter to the in_array call with the value TRUE.
The problem is with Joomla 3.3.6. I've built some modules that use this IDs to build select fields (comboboxes). In the dev machine, this select fields are built correctly, but on the production server the selected="selected" parameter is added to ALL the options.
I know I can hack the core Joomla files to correct this behavior (maybe, when creating the select fields, instead of use the == operator it should be changed to a === operator), but if I change this files Joomla updates will be a problem...
So, what can I do? If I update to PHP 5.4, will this "problem" be corrected? Should I modify the core Joomla files? Any other idea?
Upvotes: 0
Views: 128
Reputation: 13014
Testing with these inputs (a value that doesn't exist in $blacklist
)...
isSomeUser('100500000000000000683'); // should be false.
isSomeUser(100500000000000000683); // should be false.
...seems to show a bug in older versions of PHP (or in 64bit versions).
Results:
a = win 5.5.19 32bit b = win 5.4.24 32bit c = lin 5.2.5 64bit d = lin 5.3.29 64bit e = lin 5.5.9 32bit (OP development box) f = lin 5.3.10 64bit (OP production box) expected | a | b | c | d | e | f ----------|---|---|---|---|---|--- f | f | f | t | t | f | t f | t | t | t | t | t | t
Since PHP_INT_MAX
, even on a 64bit installation, is less than the input value it is converted to a float
and the second test fails for every version. This is understandably erratic behaviour.
But there is clearly something wrong with the results of c, d, and f
on the first test where true
is returned instead of the expected false
for a loose type string comparison.
The failing versions are all < 5.4 and 64bit. As I mentioned, you should anyway upgrade the production server to at least the latest 5.4. If the problem persists then I would say this is a bug in 64bit versions of PHP and should be reported as such.
Upvotes: 1