[PHP-DEV] Re: PHP 4.0 Bug #4254 Updated: 32 bit integer support misbehaving in general From: Matthew H. North (ctsmhn <email protected>)
Date: 09/15/00

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 <email protected>

At 02:35 AM 9/5/2000 +0000, you wrote:
>ID: 4254
>Updated by: sniper
>Reported By: ctsmhn <email protected>
>Status: Analyzed
>Bug Type: Scripting Engine problem
>Assigned To:
>Comments:
>
>
>
>Previous Comments:
>
>[2000-08-23 08:26:45] sniper <email protected>
>Have you tried recent versions of php4
>(from CVS or http://snaps.php.net/ ) ???
>
>--Jani
>
>---------------------------------------------------------------------------
>
>[2000-07-24 16:43:39] stas <email protected>
>Well, 0x doesn't work too good in current PHP version. This should be fixed.
>
>---------------------------------------------------------------------------
>
>[2000-07-24 16:37:10] derick <email protected>
>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 <email protected>
>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 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>