|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30695 0x80000000 treated as 0x7fffffff
Submitted: 2004-11-05 18:35 UTC Modified: 2004-11-30 08:39 UTC
From: php_bug at cklowe dot com Assigned: derick (profile)
Status: Closed Package: Math related
PHP Version: 4CVS-2004-11-05 (stable) OS: Win32
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
5 + 17 = ?
Subscribe to this entry?

 [2004-11-05 18:35 UTC] php_bug at cklowe dot com
Large integers are being saturated to the maximum signed value (0x7fffffff) as opposed to being treated as the unsigned values.  

Panic!  I had code that set the high bit in a Permissions variable when some condition was met.  

After changing PHP versions because of bug 25570, I found user reports of "Why have I got all these additional permissions?" and "I've now got Admin rights, OOoooh.  What happens if I run this SQL query in the page I now have access to?".

Reproduce code:
define ("BIG_NUM", 0x80000000);
$big_var = 0x80000000;
echo sprintf("%08x, %08x", BIG_NUM, $big_var);

Expected result:

Actual result:
7fffffff, 7fffffff


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-10 18:16 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

PHP does not support unsigned integers.

 [2004-11-10 18:37 UTC] php_bug at cklowe dot com
This is a change in behaviour.  In version 4.3.8 (for example) the expected result is displayed.  In the snapshot of a week ago, the actual result was displayed.

This is *not* a signed/unsigned integer problem (sorry if my description was unclear).  It is an initialization from a numeric literal problem.  Saturation to 0x7fffffff should not occur.  If you like, 0x80000000 should be treated as -2147483648.  Having (say) 0x80000000 treated as any ther value than 0x80000000 is surely wrong.

Forgive me for reopening this bug, but I fear I must.
 [2004-11-10 18:59 UTC]
>This is *not* a signed/unsigned integer problem 
No, why? It is.
And it can be clearly seen in this example:
define ("BIG_NUM", 0x80000000);
$big_var = 0x80000000;
printf("%u, %u\n", BIG_NUM, $big_var);
printf("%f, %f\n", BIG_NUM, $big_var);

Overflown integers are treated as floats and you cannot use bitwise operators on floats (as I understand you use them to check access privileges).
 [2004-11-10 19:30 UTC] php_bug at cklowe dot com
I see your point, and I'm happy that integers are unsigned.  

What worries me is that large hex initialisers (>= 0x80000000) are not doing their job.

This is a change in behaviour.

Python v 2.4 and above, uses Large Integers for 0x80000000 which seems acceptable.  In previous versions it did the Right Thing and treated 0x80000000 as -214783648.  Bitwise operations work as expected.

PHP did the Right Thing in version 4.3.8.  As of the current snapshot it no longer does the Right Thing.
 [2004-11-10 23:11 UTC]
THis is a change most likely caused by Joe's patches to it. I say we should revert it as it breaks too many scripts.
 [2004-11-14 23:51 UTC] php_bug at cklowe dot com
Yes, given the implications I believe a reversion would be wise.
 [2004-11-26 13:46 UTC]
gcc bugfix seems to be creating more trouble that its worth. please revert it before we release 4.3.10.
 [2004-11-26 13:53 UTC]
I don't have Zend commit access.
 [2004-11-29 09:55 UTC]
I'm on it now.
 [2004-11-29 10:40 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

 [2004-11-30 03:22 UTC] php_bug at cklowe dot com
Brilliant stuff.  I'm really glad this is fixed.

It would appear that this bug also affects version 

$big_var = 0x40000000;
echo sprintf("%08x, %08x", $big_var * 2, $big_var << 1);
----- gives ----
7fffffff, 80000000

which is OK if not entirely consistent with most other 

But there is still no way to represent bit patterns with 
the high bit set, which is a pity.

I believe your fix or an equivalent should go onto the 5 
branch, too.  
What do you think?
 [2004-11-30 08:39 UTC]
It has already been merged into both the 5.0 and 5.1 branches.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 12:01:28 2024 UTC