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 this is not your bug, you can add a comment by following this link.
If this is your bug, but 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

Add a Patch

Pull Requests

Add a Pull Request

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: Fri Mar 29 14:01:28 2024 UTC