We had an issue with searching for ISBNs and the culprit was this (int)ltrim($word, "-0").

Before jumping to wrong conclusions I tried this:

$str1 = "1234567891";
$str2 = "12345678912";

print (int)ltrim($str1, "-0");   // Outputs 1234567891
print (int)ltrim($str2, "-0");   // Outputs 2147483647

Is there anything I am missing?

Comments

kbahey’s picture

kbahey commented
Status: Active » Postponed (maintainer needs more info)

Odd, but I can't reproduce it ...

Using this:

$str1 = "1234567891";
$str2 = "12345678912";

print (int)ltrim($str1, "-0") . "\n";  // Outputs 1234567891
print (int)ltrim($str2, "-0") . "\n";  // Outputs 2147483647

And running it as:

$ php y.php
1234567891
12345678912

Gets me the expected results. PHP 5.2.4 on Ubuntu server 64 bit.

owahab’s picture

owahab commented
Status: Postponed (maintainer needs more info) » Active

Khaled, your results make sense. I am running a 32 bit version of Gentoo, my integer range is −2,147,483,648 to +2,147,483,647 thus I get this error while you don't.

If you tried with a bigger (greater) integer on the same 64 bit machine you will reach the same result.

My point is: why cast a search string to an integer knowing that this might scramble the integer on some or maybe many systems, consequently compromising the accuracy of the search module?

I am sure Steven had some point about the (int)ltrim($word, "-0") but I have no clue what that point was.

The interesting thing is: this bug is probably carried upstream since this line was committed like 3 years ago which made me ask if I am missing something.

kbahey’s picture

kbahey commented

I can confirm the problem does exist on 32-bit Linux.

$str1 = "1234567891";
$str2 = "12345678912";

print (int)ltrim($str1, "-0") . "\n";  // Outputs 1234567891
print (int)ltrim($str2, "-0") . "\n";  // Outputs 2147483647

$ php x.php
1234567891
2147483647

Same Ubuntu version, same PHP version (5.2.4), but 32bit.

Yes, this needs to be fixed.

kbahey’s picture

kbahey commented

Casting to a float makes it work correctly.

$str1 = "1234567891";
$str2 = "12345678912";

print (float)ltrim($str1, "-0") . "\n";  // Outputs 1234567891
print (float)ltrim($str2, "-0") . "\n";  // Outputs 2147483647

$ php x.php
1234567891
12345678912

I am not sure if that would have side effects.

owahab’s picture

owahab commented

I agree with you Khaled that casting to float will fix this behavior though I am sure we can find a better solution since the same reported behavior will occur with values greater than platform float size.

I also found an interesting warning here that reads:

Never cast an unknown fraction to integer, as this can sometimes lead to unexpected results.

Thus, fractions will also produce unknown results. IMO, casting to an integer produces more issues than it fixes.

sin’s picture

sin commented

Stumble upon this issue using Drupal 6.4 and PHP 5.1.6.

sin’s picture

sin commented

Why we cast to int at all? Is that makes a difference word or number for indexing?

sin’s picture

sin commented
Version: 5.x-dev » 6.x-dev

I thought about it and decided this (int) is intended to cut fractional part to find nodes containing "100.01" and nodes containing "100.02" while searching for "100" keyword, for example. This simplifies index and maybe has some usability reasons. So cast to float would not work. I beleive what we need here is to cut a number before dot as a string. Am I right?

mchaplin’s picture

mchaplin commented

I believe this to be 2 seperate issues

http://drupal.org/node/385824

and

http://drupal.org/node/385812

jhodgdon’s picture

jhodgdon
she/her
Primary language English
commented
Status: Active » Closed (duplicate)

This is a duplicate of #74673: Search does not correctly handle large numbers (> maxint) so you cannot search by UPC code for example