php.net |  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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php_bug at cklowe dot com
New email:
PHP Version: OS:

 

 [2004-11-05 18:35 UTC] php_bug at cklowe dot com
Description:
------------
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:
----------------
80000000,80000000

Actual result:
--------------
7fffffff, 7fffffff

Patches

Pull Requests

History

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

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] tony2001@php.net
>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] derick@php.net
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] edink@php.net
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] jorton@php.net
I don't have Zend commit access.
 [2004-11-29 09:55 UTC] derick@php.net
I'm on it now.
 [2004-11-29 10:40 UTC] derick@php.net
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
http://snaps.php.net/.
 
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 
5.0.2.

$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 
languages.  

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] derick@php.net
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 Dec 22 02:01:28 2024 UTC