Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:10543
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: <joelee@joeworks.com>
To: "'Stefan Esser'" <sesser@php.net>
Cc: <internals@lists.php.net>
Date: Wed, 16 Jun 2004 20:30:29 +0100
Organization: Joeworks
Message-ID: <916EFAA7BAA5D5119A7200E0291BBFCC71261E@darwin.journeys.travel>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <40D07D35.4060602@php.net>
Importance: Normal
Subject: RE: [PHP-DEV] 64 bit safety...
From: joelee@joeworks.com ("Joseph Lee")
References: <40D07D35.4060602@php.net>

While this is being fixed:

 1. Does that mean PHP on 64-bit is declared not safe for Production
use?

 2. Will it be safe on Linux AMD64, if we compiled PHP with
CFLAGS="-m32" ?


I have noticed on both release of PHP4.3.7 & PHP5.0.0RC3, there are some

failures during "make test", if compiled without CFLAGS="-m32" 

Joe Lee


-----Original Message-----
From: Stefan Esser [mailto:sesser@php.net] 
Sent: Wednesday, June 16, 2004 6:03 PM
To: internals@lists.php.net
Subject: [PHP-DEV] 64 bit safety...


Hi,

seems some parts... especially sqlite are not 64bit safe.

If you want to do something productive go out and search for 
zend_parse_parameter calls where l is not writing to a long (NOT int)
and where the strlen of a s is not written into an int.

F.e. in sqlite there seems to be several places where the strlen of a s 
is written into a long instead of an int. This will all break bigtime on

64bit systems where int is 32 bit but long is 64 bit.

Stefan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php