Everything

php

64 bit safety...

php.internals

Stefan Esser

22 years ago

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

Joseph Lee

22 years ago

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

Sara Golemon

22 years ago

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

Ard Biesheuvel

22 years ago

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

Stefan Esser

22 years ago

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

Sascha Schumann

22 years ago

> 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