> 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
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 wit
