> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
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
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
> 1. 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 :)
> 2. 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-is
test", if compiled without CFLAGS="-m32"
Joe Lee
-Original Message-
From: Stefan Esser [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 2004 6:03 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] 64 bit safety...
Hi,
seems some parts... especially sqlite are not 64bit
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
