The following code is causing an error on PHP 4.3.9 on CentOS 4.8:

      if ($value > PHP_INT_MAX) {
        $precision = ini_get('precision');
        @ini_set('precision', 16);
        $value = sprintf('%.0f', $value);
        @ini_set('precision', $precision);
      }

The problem is with the constant PHP_INT_MAX, which is not defined in that version of PHP. As Drupal 6 requires at least PHP 4.3.5, I would expect it to work with PHP 4.3.9 included in CentOS 3.8.

[Edited by KiamLaLuno to correct the reference to the operating system, and to correct the reference to the Drupal requirements]

Comments

avpaderno’s picture

The reported code is present in _db_query_callback().

If the problem is with the version of PHP included in CentOS 4.8, then the requirements page should contain a warning about that.

hd’s picture

According to http://www.php.net/manual/en/reserved.constants.php since PHP 4.4.0 and PHP 5.0.5, there is a (new) PHP_INT_MAX constant. The documented Drupal 6.x requirements are PHP 4.3.5.

However, just updating the Drupal requirements does not really solve the problem. It is not good to introduce an urgent Drupal core security update (6.14) which all in a sudden requires a later PHP version. Especially when presumably many sites are running CentOS 4.8 ie Red Hat Enterprise Linux 4.8 and thus are stuck with PHP 4.3.9. I do not know the programming details and reasonings here, but perhaps the usage of PHP_INT_MAX in _db_query_callback() could have been avoided?

Also I do not know when _db_query_callback() in database.inc is running into this very piece of code with PHP_INT_MAX and thus wonder when this problem will surface next. (So far I only experienced it when trying to update the nodewords module to version 6.x-1.1).

Wonder whether it would be possible for affected sites to change the Drupal 6.14 code

    case '%d': // We must use type casting to int to convert FALSE/NULL/(TRUE?)
      $value = array_shift($args);
      // Do we need special bigint handling?
      if ($value > PHP_INT_MAX) {
        $precision = ini_get('precision');
        @ini_set('precision', 16);
        $value = sprintf('%.0f', $value);
        @ini_set('precision', $precision);
      }
      else {
        $value = (int) $value;
      }
      // We don't need db_escape_string as numbers are db-safe.
      return $value;

back to the Drupal 6.13 version

    case '%d': // We must use type casting to int to convert FALSE/NULL/(TRUE?)
      return (int) array_shift($args); // We don't need db_escape_string as numbers are db-safe

without new adverse side effects.

hd’s picture

Replying to myself:

Found thousands of error messages in the HTTPD log files like:

PHP Notice: Use of undefined constant PHP_INT_MAX - assumed 'PHP_INT_MAX' in /var/www/japaninc/drupal-6.14/includes/database.inc on line 213

... which required some sort action.

Running CentOS 4.8, I enabled the CentOSPlus Repository and thus updated to PHP 5.1.6 and MySQL 5.0.82.

See also:

http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus?actio...

http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus/CentO...

http://wiki.centos.org/PackageManagement/Yum/Priorities

Note: When enabling the CentOS web stack, perl is excluded – which is generally correct – except that dependencies require (currently) 5.8.8 whereas that is not provided by the base repos. If you experience that, you will get a message like:

Error: Missing Dependency: perl(:MODULE_COMPAT_5.8.8) is needed by package perl-DBD-MySQL

The way to fix that is to change the priority of CentOS Plus to 1 temporarily,
$yum clean all
$yum install perl
... which should install Perl 5.8.8.

Important: Set CentOS Plus priority back where you had it (presumably 2), and go back to what you were doing.

(Found this Perl dependency hint elsewhere and cannot remember the URL.)

winful’s picture

I had this problem when updating to Drupal 6.14. My php version is 4.3.9.
This code (excluding the opening and closing php tags) from the comments section on http://php.net/manual/en/reserved.constants.php, when pasted into the top of database.inc, got rid of the error messages and "appears" to be working fine.

function get_int_max() 
{ 
    $max=0x7fff; 
    $probe = 0x7fffffff; 
    while ($max == ($probe>>16)) 
    { 
        $max = $probe; 
        $probe = ($probe << 16) + 0xffff; 
    } 
    return $max; 
} 

if (!defined('PHP_INT_MAX')) 
{ 
    define ('PHP_INT_MAX', get_int_max()); 
} 
define ('PHP_INT_MIN', (int)(PHP_INT_MAX+1)); 
emok’s picture

I confirm this bug, as I am also on an old php version (4.3.11).
I guess it would be better to move everything (the function definition and the PHP_INT_MIN-definition) into the if-bracket, to avoid redefining MIN and performing unnecessary work when we are running a PHP-version that already has defined it.

quinnhigurashi’s picture

Version: 6.14 » 6.16

I found my case the same or similar as above. PHP_INT_MAX is used in /includes/database.inc, failed to upgrade to 6.16 from 5.x on PHP4.3.9 on CentoOS4.

As If’s picture

Also similar to the above. Failed to upgrade to 6.16 from 5.x on PHP4.3.9 on RedHat Linux 2.6.9-42.0.8.ELsmp. Winful's function (#4) got me past the error.

_snake_’s picture

Hi

I have the same problem

PHP Notice:  Use of undefined constant PHP_INT_MAX - assumed 'PHP_INT_MAX' in /srv/www/htdocs/webs/drupal/includes/database.inc on line 213

I'm using Drupal 6.15, Apache 2.0.53, PHP 5.0.3 and MySQL 4.1.10a. Is there another solution to this issue without insert the code listed above in database.inc?

Thanks

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.