RE: PHP 4.0 Bug #4254 Updated: 32 bit integer support misbehaving in general
| From: | Matthew H. North | Date: | Mon, 20 Nov 2000 17:03:29 +0000 |
| Subject: | RE: PHP 4.0 Bug #4254 Updated: 32 bit integer support misbehaving in general | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-38630@lists.php.net to get a copy of this message | ||
Still does not work. Here is the output from 4.0.3pl1:
2147483647
0
0
0
0
0
4294967294
-1879048208
2147483647
I don't do CVS, so I can't test the *latest* latest. Perhaps it's some
support I'm compiling in? Here are my updated 'configure' options:
CUSTOM_ODBC_LIBS="-L/usr/local/postgres/lib -lpsqlodbc"
./configure --with-apache=../apache-1.3.14 --without-mysql --with-custom-odb
c=/usr/local/postgres --with-pgsql=/usr/local/postgres --enable-trans-sid --
with-sysvsem --with-sysvshm --enable-wddx
This is being compiled and run on Intel-based FreeBSD 3.x-STABLE.
Matthew H. North
Software Engineer
CTSnet Internet Services
t (858) 637-3600
f (858) 637-3630
mailto:ctsmhn@cts.com
-----Original Message-----
From: Bug Database [mailto:php-dev@lists.php.net]
Sent: Sunday, November 19, 2000 3:49 AM
To: ctsmhn@cts.com
Subject: PHP 4.0 Bug #4254 Updated: 32 bit integer support misbehaving
in general
ID: 4254
Updated by: stas
Reported By: ctsmhn@cts.com
Status: Feedback
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Please try latest version and report if it works.
Previous Comments:
---------------------------------------------------------------------------
[2000-08-23 21:40:43] sniper@php.net
I think the user misunderstood Stas's comment. (I did too..)
It should be fixed but it hasn't been fixed yet.
I tried this myself with the latest CVS and got the same results as derick.
--Jani
---------------------------------------------------------------------------
[2000-08-23 08:26:45] sniper@php.net
Have you tried recent versions of php4
(from CVS or http://snaps.php.net/ ) ???
--Jani
---------------------------------------------------------------------------
[2000-07-24 16:43:39] stas@php.net
Well, 0x doesn't work too good in current PHP version. This should be fixed.
---------------------------------------------------------------------------
[2000-07-24 16:37:10] derick@php.net
I tried it here and got the folowing results (with 4.0.1pl2):
2147483647
1.9999999995343
1.1249999995343
1.2499999995343
1.1249999930151
1.0000000004657
4294967294
-1879048208
2147483647
It's very strange, $var2 to $var5 are suddenly floating point numbers.
Zeev, Andi? Could someone tell what's going on here?
---------------------------------------------------------------------------
[2000-04-26 18:06:07] ctsmhn@cts.com
Try something like this:
$var1 = 0x7FFFFFFF;
$var2 = 0xFFFFFFFF;
$var3 = 0x8FFFFFFF;
$var4 = 0x9FFFFFFF;
$var5 = 0x8FFFFFF1;
$var6 = 0x80000001;
$var7 = $var1 + 0x7FFFFFFF;
$var8 = (0x08FFFFFF << 4);
$var9 = intval("AFFFFFFF", 16);
echo $var1; echo "n";
echo $var2; echo "n";
echo $var3; echo "n";
echo $var4; echo "n";
echo $var5; echo "n";
echo $var6; echo "n";
echo $var7; echo "n";
echo $var8; echo "n";
echo $var9; echo "n";
Results:
2147483647
0
0
0
0
0
4294967294
-1879048208
2147483647
("n" is separated so we don't accidentally cause the interpreter to convert
the vars to strings before printing them)
var1 prints out (correctly) 2147483647
var2 prints out 0, leading me to believe that PHP deals with integers as
signed 32-bit, by default (even though FFFFFFFF should be -1, not 0).
However, if that's the case, var4 through var6 should print out some version
of a negative number. Instead they print out 0 as well.
Then, looking at var7, we see that you *can* assign and print a value
greater than 7FFFFFFF in unsigned mode, *if* you add to it to increment the
value to that size, as opposed to directly assigned it using the '0x'
operator. However, var8 shows that shifting left doesn't afford the same
'convenience'.
Using intval doesn't help either. As you can see from var9, not only does
intval not translate AFFFFFFF to the proper unsigned 32 bit integer, it
doesn't even translate it to the proper signed 32 bit integer! In fact,
it's as if the 32nd bit is forcibly turned off - *any* hex number beyond
7FFFFFFF is returned by intval as 2147483647.
At the very least all of these operations should have consistent behavior.
Preferably there would be a way to specify signed or unsigned operations as
well. And it would be *really* nice to have an unsigned type.
./configure --with-apache=../apache_1.3.12i --enable-sysvsem --enable-sysvsh
m --enable-wddx --enable-xml --with-pgsql=/usr/local/postgres --enable-track
-vars --enable-trans-sid --enable-session
---------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view the
rest of the comments, please view the bug report online.
Full Bug description available at: http://bugs.php.net/?id=4254