Re: PHP 4.0 Bug #4254 Updated: 32 bit integer support misbehaving in general

Well, we are currently using 4.0.1pl2 and the problem still exists. We have also tried to compile 4.0.2 in combination with Apache, but something in 4.0.2 breaks the Apache configure script: ./configure --sbindir=/usr/local/apache/sbin --activate-module=src/modules/php4/libphp4.a --enable-module=access --enable-module=alias --enable-module=asis --enable-module=auth --enable-module=auth_db --enable-module=autoindex --enable-module=cgi --enable-module=dir --enable-module=env --enable-module=imap --enable-module=include --enable-module=info --enable-module=log_config --enable-module=mime --enable-module=negotiation --enable-module=setenvif --enable-module=status --disable-module=actions --disable-module=auth_anon --disable-module=auth_dbm --disable-module=cern_meta --disable-module=digest --disable-module=example --disable-module=expires --disable-module=headers --disable-module=log_agent --disable-module=log_referer --disable-module=mime_magic --disable-module=mmap_static --disable-module=proxy --disable-module=rewrite --disable-module=so --disable-module=speling --disable-module=unique_id --disable-module=userdir --disable-module=usertrack Configuring for Apache, Version 1.3.9 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for FreeBSD 4.1 platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules

    o db_auth_module uses ConfigStart/End
      using Berkeley-DB/1.x for mod_auth_db (-lc)
    o php4_module uses ConfigStart/End

+ checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. This is most likely because your C compiler ** is not ANSI. Apache requires an ANSI C Compiler, such ** as gcc. The above error message from your compiler ** will also provide a clue. Aborting! If I remove the src/modules/php4 directory and do a gmake install in the php-4.0.1pl2 directory, this annoying error goes away. Sigh. Matthew H. North Software Engineer CTSnet Internet Services t (858) 637-3600 f (858) 637-3630 mailto:ctsmhn@cts.com At 02:35 AM 9/5/2000 +0000, you wrote:

ID: 4254 Updated by: sniper Reported By: ctsmhn@cts.com Status: Analyzed Bug Type: Scripting Engine problem Assigned To: Comments: Previous Comments: [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-sysvshm --enable-wddx --enable-xml --with-pgsql=/usr/local/postgres --enable-track-vars --enable-trans-sid --enable-session --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=4254