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
While this is being fixed:
-
Does that mean PHP on 64-bit is declared not safe for Production
use? -
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
- Does that mean PHP on 64-bit is declared not safe for Production
use?
It means it's not as heavily tested as on 32bit platforms :)
- Will it be safe on Linux AMD64, if we compiled PHP with
CFLAGS="-m32" ?
iirc, Linux treats both int and long as 64bit datatypes so it'd be a
non-issue there. The concern is platforms which treat int and long as
different sizes. Watch your configure output for:
checking size of long...X
checking size of int...Y
If X and Y are the same you're fine. If they're different, then any
extension which abuses zend_parse_parameters by using the wrong data types
will have issue. There's also the possibility that some folks are using
entirely different data types like size_t which can depend on other factors
such as LFS. The good news is that it doesn't take much to scan through for
problems like that and fix them.
Anyone up for a bugsquash?
-Sara
Sara Golemon wrote:
iirc, Linux treats both int and long as 64bit datatypes so it'd be a
non-issue there. The concern is platforms which treat int and long as
different sizes. Watch your configure output for:
Actually, (un)signed ints are 32-bit on all 64-bit platforms I know of
(Linux/[Free]BSD/Tru64 on Alpha, Sparc64) Don't know about 64-bit PCs,
but I would expect OSes to be consistent across platforms.
Anyone up for a bugsquash?
Sure!
--
Ard
Ard Biesheuvel wrote:
Actually, (un)signed ints are 32-bit on all 64-bit platforms I know of
(Linux/[Free]BSD/Tru64 on Alpha, Sparc64) Don't know about 64-bit PCs,
but I would expect OSes to be consistent across platforms.
Systems are usually
ILP32 - Integer / Long / Pointers 32 bit
or
LP64 - Long / Pointers 64 bit - but int 32 bit
And no... int is not 64 bit on 64 bit Linux. This was one of the reasons
why I saw some of the bugs, because I tested PHP on an alpha cpu running
with debian linux.
Stefan Esser
will have issue. There's also the possibility that some folks are using
entirely different data types like size_t which can depend on other factors
such as LFS.
s/size_t/off_t/
- Sascha