Re: [PHP-DEV] 64bit PHP on solaris

[James Devenish]

In message [EMAIL PROTECTED]
on Fri, Mar 14, 2003 at 05:22:11PM +, Wez Furlong wrote:
 Please coordinate with me on streams issues; if some 64bit oses
 declare descriptors as longs rather than ints, then we could have a
 bigger job on our hands (similar to the mess with socket types under
 win32).

Regardless of any potential disasters with _php_stream_cast, there are
at least a few unsubtle storage-type conflicts. In my case, fds are
stored as ints but PHP casts them to pointers.

In message [EMAIL PROTECTED]
on Fri, Mar 14, 2003 at 11:00:50AM -0500, David Hill wrote:
 Sorry but I don't commit what I don't understand, and the three streams
 files needed some more understanding on my part. In those areas the php5
 head differs quite a bit from the 4_3 stream.

Regardless of what you personally understand (and what I personally
understand), my point would be that the problems are simply unfixed
by *anyone*.

Even so, I don't know what would be hard for anyone to understand about
my patches (and no-one has asked me in the past). If you think there
simply too many of them, most of them are probably whitespace
disagreements between what you committed and what the PHP style appears
to be. The basis of all my streams patches is like this (from the old
streams.c):

Index: main/streams.c
===
RCS file: /repository/php4/main/Attic/streams.c,v
retrieving revision 1.125.2.37
diff -u -u -r1.125.2.37 streams.c
--- main/streams.c  6 Mar 2003 20:58:19 -   1.125.2.37
+++ main/streams.c  8 Mar 2003 10:48:16 -
@@ -1532,7 +1532,7 @@
}
if (ret) {
fflush(data-file);
-   *ret = (void*)fd;
+   *(int*)ret = fd;
}
return SUCCESS;
default:

What have I done? Well, someone's taking fd (declared as an 'int', which
may be 32 bits on some systems), casting it a void* (a 64-bit value on
some systems) and then stuffing that into storage space which, although
it might not be obvious, happens to be only 32 bits wide. My patch takes
fd (the 'int') and stuffs it into 'int' storage. Now that's not to say
that the destination IS actually an 'int' but merely that I am keeping
the int at its original width rather than casting it up. It's not a
'perfect solution', but it's not a 'perfect problem', either.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[James Devenish]

In message [EMAIL PROTECTED]
on Thu, Mar 13, 2003 at 02:05:45PM -0500, David Hill wrote:
   first file_get_contents  readfile both core dump with bus errors
 b/c
   the file descriptors are typed as int's when they should be longs
   (steams.c lines 1020/1156)
 
 The lines don't match up to the current code... if you could tell me
 based on the current lines or give me a code snippet

CRIPES, people! I posted patches in November 2002 (admittedly, it was a
large patch and probably no one got to check it all out). Then, I
reposted them (and sent then directly to you, Dave!) a few days ago.




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Further outstanding 64-bit issues with PHP_4_3

[James Devenish]

Hi,

Just looking at CVS diffs (can't compile at the moment due to
./configure breakage), I can see...

Remaining zend_parse_parameters problems:

php4/ext/ftp/php_ftp.c
php4/ext/sockets/sockets.c

General LP64 incompatabilities left over from my November patches:

php4/ext/pgsql/pgsql.c
php4/ext/standard/url_scanner.c
php4/ext/standard/url_scanner_ex.c

php4/main/network.c
php4/main/streams.c
(Need to check: is _php_stream_cast safe? If not, then
main/streams/cast.c in HEAD is probably not)
php4/main/streams/plain_wrapper.c
php4/main/streams/xp_socket.c

And of course the OnUpdateLong stuff, but I guess that's in process.

Index: ext/ftp/php_ftp.c
===
RCS file: /repository/php4/ext/ftp/php_ftp.c,v
retrieving revision 1.74.2.5
diff -u -u -r1.74.2.5 php_ftp.c
--- ext/ftp/php_ftp.c   7 Mar 2003 13:42:13 -   1.74.2.5
+++ ext/ftp/php_ftp.c   8 Mar 2003 10:48:15 -
@@ -470,7 +470,7 @@
php_stream  *stream;
char*file;
int file_len;
-   longmode, resumepos=0;
+   longmode, resumepos=0;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rrsl|l, z_ftp, 
z_file, file, file_len, mode, resumepos) == FAILURE) {
return;
@@ -843,7 +843,7 @@
char*remote, *local;
int remote_len, local_len;
longmode, startpos=0;
-   php_stream * instream;
+   php_stream  *instream;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rssl|l, z_ftp, 
remote, remote_len, local, local_len, mode, startpos) == FAILURE) {
return;
@@ -897,8 +897,8 @@
ftptype_t   xtype;
char*remote, *local;
int remote_len, local_len, ret;
-   int mode, startpos=0;
-   php_stream * instream;
+   longmode, startpos=0;
+   php_stream  *instream;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rssl|l, z_ftp, 
remote, remote_len, local, local_len, mode, startpos) == FAILURE) {
return;
Index: ext/sockets/sockets.c
===
RCS file: /repository/php4/ext/sockets/sockets.c,v
retrieving revision 1.125.2.4
diff -u -u -r1.125.2.4 sockets.c
--- ext/sockets/sockets.c   7 Mar 2003 13:42:18 -   1.125.2.4
+++ ext/sockets/sockets.c   8 Mar 2003 10:48:15 -
@@ -776,7 +776,7 @@
php_socket  *php_sock;
char*tmpbuf;
int retval;
-   longlength, type = PHP_BINARY_READ;
+   longlength, type = PHP_BINARY_READ;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rl|l, arg1, length, 
type) == FAILURE)
return;
@@ -966,7 +966,7 @@
struct sockaddr_un  s_un;
char*addr;
int retval, addr_len;
-   longport;
+   longport;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rs|l, arg1, addr, 
addr_len, port) == FAILURE)
return;
@@ -1035,7 +1035,7 @@
php_socket  *php_sock;
char*addr;
int addr_len;
-   int port = 0;
+   longport = 0;
longretval = 0;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rs|l, arg1, addr, 
addr_len, port) == FAILURE)
@@ -1316,7 +1316,7 @@
char*recv_buf;
php_socket  *php_sock;
int retval;
-   longlen, flags;
+   longlen, flags;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rzll, php_sock_res, 
buf, len, flags) == FAILURE)
return;
@@ -1358,7 +1358,7 @@
zval*arg1;
php_socket  *php_sock;
int buf_len, retval;
-   longlen, flags;
+   longlen, flags;
char*buf;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rsll, arg1, buf, 
buf_len, len, flags) == FAILURE)
@@ -1387,7 +1387,7 @@
struct sockaddr_in  sin;
socklen_t   slen;
int retval;
-   longarg3, arg4;
+   longarg3, arg4;
char*recv_buf, *address;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rzllz|z, arg1, arg2, 
arg3, arg4, arg5, arg6) == FAILURE)

Re: [PHP-DEV] [PATCH] fixes for /usr/lib64 systems

[James Devenish]

In message [EMAIL PROTECTED]
on Thu, Mar 06, 2003 at 10:25:14AM +, Joe Orton wrote:
 Hi, I've got a bunch of fixes for systems which have system libraries in
 /usr/lib64 rather than /usr/lib - these are needed for some upcoming
 64-bit Linux ports.  These fixes are based on patches from SuSE
 developers [EMAIL PROTECTED] [EMAIL PROTECTED].
 
 Should I submit changes to ext/*/config.m4 in bulk or individually? 
 
 Here's the first fix to prevent adding /usr/lib64 to LDFLAGS:
[...]
 +-L/usr/lib|-L/usr/lib/|-L/usr/lib64|-L/usr/lib64/) ;;

Of all the problems I've had using PHP on 64-bit platforms (e.g. bug
#21973, which refers mainly to lib directory naming under commercial
64-bit environments), this was not one of them -- yay.

So I am curious:
 - What is the purpose of having the mechanism to remove or not remove
   /usr/lib (and why not do the same for /lib and other vendor
   directories)?
 - Why do 64-bit Linux operating systems need the special hard-coded
   treatment?
 - Will the same be done for other operating systems?




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] fixes for /usr/lib64 systems

[James Devenish]

In message [EMAIL PROTECTED]
on Thu, Mar 06, 2003 at 11:52:15AM +, Joe Orton wrote:
 /usr/lib64 exists so that you can have 64-bit libraries installed
 alongside 32-bit libraries in /usr/lib - this is a precedent that comes
 from Sun or SGI or somewhere I believe.

Yep, HP-UX does it, too.

 (In fact I think you can get /usr/lib32 as well for some IRIX/MIPS,
 since there are two different flavours of 32-bit ABI)

Sure. Sometimes lib-and-lib32 or lib-and-lib64 or lib-and-lib/sparcv9
or lib-and-lib/pa20_64.

 Adding /usr/lib64 or /usr/lib to the library search path at minimum
 causes a re-ordering of the library search path, which means in some
 circumstances you pick up the wrong versions of libraries.
[...]
 e.g. if you have a libfoo in /usr/lib, but you want to compile against a
 different version you have installed in /home/jim/lib, you start with
 -L/home/jim/lib -lfoo.  If the configure script then adds -L/usr/lib to
 LDFLAGS, you might end up with the system libfoo again, which is wrong.

Sure, my question is whether (and why) /usr/lib and /usr/lib64 should be
preferentially treated.

 On a lib64 system, if you do have the 32-bit libraries installed in
 /usr/lib, but want to compile against the 64-bit libraries in
 /usr/lib64, adding /usr/lib to the library search path breaks everything
 horribly, since you pick up the 32-bit libc etc.

Okay, so 64-bit Linux needs the path hack because it will try and use
32-bit binaries with its 64-bit ABI instead of recognising that the
32-bit binaries cannot be used and skipping over them? Is that what
you're saying?



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] fixes for /usr/lib64 systems

[James Devenish]

In message [EMAIL PROTECTED]
on Thu, Mar 06, 2003 at 12:15:43PM +, Joe Orton wrote:
 Yes, that's why it is needed - though I'm surprised if this problem is
 unique to the linker used on Linux.
[...]
 I'm fairly sure I've had problems on IRIX before when the linker picks
 up libraries with a different ABI.

Okay, thanks for the clarification.

The reason it might not have come up for me is that on systems I use,
the vendor's linker is used. On an UltraSPARC II test box with gcc using
Sun's ccs linker:

solaris$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.1/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.2.1
solaris$ /usr/bin/echo '#include stdio.h\nint main(void) { printf(Hello 
World!\\n); }'  hello.c
solaris$ gcc -m32 -o hello32 hello.c
solaris$ gcc -m64 -o hello64 hello.c
solaris$ file hello32
hello32: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), dynamically linked (uses 
shared libs), not stripped
solaris$ file hello64
hello64: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically linked 
(uses shared libs), not stripped
solaris$ LDPATH=-L/usr/lib\ -L/usr/lib/sparcv9 gcc -m64 -o hello64 hello.c
solaris$ ldd hello64
libc.so.1 = /usr/lib/sparcv9/libc.so.1
libdl.so.1 =/usr/lib/sparcv9/libdl.so.1
/usr/platform/SUNW,Ultra-5_10/lib/sparcv9/libc_psr.so.1

On an Itanium host:

hp-ux$ gcc -v
Reading specs from /usr/local/lib/gcc-lib/ia64-hp-hpux11.20/3.0/specs
Thread model: posix
gcc version 3.0
hp-ux$ gcc -o hello32 hello.c
hp-ux$ file hello32
hello32:ELF-32 executable object file - IA64
hp-ux$ ldd hello32
libc.so.1 =/lib/hpux32/libc.so.1
libdl.so.1 =   /usr/lib/hpux32/libdl.so.1
/opt/graphics/OpenGL/lib/hpux32/libogltls.so = 
/opt/graphics/OpenGL/lib/hpux32/libogltls.so
hp-ux$ LDPATH=/lib/hpux64\ /lib/hpux32 gcc -o hello32 hello.c
hp-ux$ ldd hello32
libc.so.1 =/lib/hpux32/libc.so.1
libdl.so.1 =   /usr/lib/hpux32/libdl.so.1
/opt/graphics/OpenGL/lib/hpux32/libogltls.so = 
/opt/graphics/OpenGL/lib/hpux32/libogltls.so
hp-ux$ cc +DD64 -o hello64 hello.c
hp-ux$ file hello64
hello64:ELF-64 executable object file - IA64
hp-ux$ ldd hello64
libc.so.1 =/usr/lib/hpux64/libc.so.1
libdl.so.1 =   /usr/lib/hpux64/libdl.so.1
hp-ux$ LDPATH=/lib/hpux32\ /lib/hpux64 cc +DD64 -o hello64 hello.c
hp-ux$ file hello64
hello64:ELF-64 executable object file - IA64
hp-ux$ ldd hello64
libc.so.1 =/usr/lib/hpux64/libc.so.1
libdl.so.1 =   /usr/lib/hpux64/libdl.so.1

(Acutally, I'm not sure that the last example attempted to do what I
wanted it to do.)



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[James Devenish]

In message [EMAIL PROTECTED]
on Wed, Mar 05, 2003 at 07:24:20AM +0200, Andi Gutmans wrote:
 It might be less confusing to just have one.

Hasn't worked so far ;)



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[James Devenish]

In message [EMAIL PROTECTED]
on Wed, Mar 05, 2003 at 07:35:49AM +0200, Andi Gutmans wrote:
 At 01:29 PM 3/5/2003 +0800, James Devenish wrote:
 In message [EMAIL PROTECTED]
 on Wed, Mar 05, 2003 at 07:24:20AM +0200, Andi Gutmans wrote:
 Hasn't worked so far ;)
 
 Well we're talking about changing the name from OnUpdateInt to 
 OnUpdateLong. It should reduce confusion.

Hence the 'winking smiley'. But on the other hand, using 'long' in
the zend_parse_parameters interface didn't prevent confusion.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] - 64 bit issue with zend_parse_parameters calls

[James Devenish]

In message [EMAIL PROTECTED]
on Sat, Mar 01, 2003 at 02:43:59PM -0500, Dave Hill wrote:
 Interestingly enough I did find one coding error, in
 ext/w32api/w32api.c there are two calls with s|l and only
 two arguments passed into the function, so heaven help anyone
 who tries to pass that optional long :-) I guess it is lucky
 that I am using Apache/Unix :-)

Rest assured that there was at least one such incident affecting
Apache/UNIX when I did this last year (but IIRC it has been
fixed since then).



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[James Devenish]

Hi,

Preface: This e-mail uses the distribution list (To and CC addresses)
that the original poster used. I have moved everyone other than php-dev
to Bcc so that this doesn't get perpetuated (I have no idea of the
significance of the other addresses that were e-mailed, nor do I know
Dave Hill's standing in the PHP community).

In message [EMAIL PROTECTED]
on Thu, Feb 27, 2003 at 02:52:28PM -0500, Dave Hill wrote:
 Proposed Patch to address 64 bit issues in PHP v4.3.1
 Diff -u against php4-STABLE-200302241430
 Also needed in 4.5.x and 5.x
 Addresses bugs 20994, 21002, 21822, 20268

There was some discussion on php-dev in November 2002 after I posted
patches for bug #20268 (the earliest-numbered one in Dave's list).

 I chose to address this problem by creating OnUpdateLong (in addition to
 to existing OnUpdateInt) and sweep though the code changing the call
 where needed to match the stucture item. An equally valid fix would be
 to change all of those longs to ints.

(a) I also chose to create OnUpdateLong (and this has been working well
for me since 4.3.0pre2 using the patches I posted). Since I posted those
patches, PHP has progressed and more of these problems have been
introduced (bad) but at the same time some of the test cases have been
revised to be more portable (good).

(b) I found that sometimes ints needed to stay as ints and longs needed
to stay as longs, which is why I chose to separate OnUpdateLong from
OnUpdateInt.

(c) In discussions on php-dev in November, the subject of the thread was
64-bit PHP 4.3 (extensive long vs int problems)
http://marc.theaimsgroup.com/?t=10369029101r=1w=2

(d) Jason Greene responded as a person who was working on this problem.
Disfavour of the OnUpdateLong solution was expressed (on- and maybe
off-list, too).

 After performing that sweep, I found there was a small number of other
 errors of the int/long type that my compiler found that I corrected and
 are included here. There might be more mix and match problems, I only
 addressed the ones in the modules I have enabled.

Deja vu!

Now the reason I am responding and the reason I have BCCed the people in
Dave's list was that I wanted to mention something about Zend. Really,
this bug has its roots in Zend though it is manifested in PHP modules.
Firstly, OnUpdateInt assigns to long storage but uses zend_atoi --
clearly there is confusion already. But the more disturbing thing that I
found in November was the Zend documentation for zend_parse_parameters
(a site of extensive long/int problems). That is why I have written this
e-mail.

I know nothing about the Zend engine but I will refer to this document:
http://www.zend.com/apidoc/zend.arguments.retrieval.php It is entitled
Accepting Arguments / Retrieving Arguments and describes the
zend_parse_parameters function. It lists a type specifier:

l - long

But it does not list an int type. In the actual code, it is entirely
long-based, not int-based, so there is clearly a mismatch. But moreover,
there is no acknowledgement of the significance of int versus long. So
it is not surprising that so many developers have made mistakes arising
from this.

Therefore, I thought that a proper solution to this problem would have
to involve some consideration of the Zend API (or at least copious
acknowledgments and warnings in its documentation). There is potentially
a huge developer education problem, too. That is why I chose to add
OnUpdateLong. And given the choice, I would have 'i - int' added to the
type specifiers of zend_parse_parameters.

Firstly, having the OnUpdateLong function allows quick rectification of
these problems without having to try to stuff ints into longs or longs
into ints -- we can instead just choose the one that fits the task.
Moreover: by having two functions and two type specifiers (one for ints
and one for longs), the situation would almost be self-documenting:
developers that would usually neglect to consider the difference between
int and long would at least see that there is a 'int' variant and a
'long' variant and therefore be prompted -- without extensive
re-education -- to consider using the correct 'hole' for the 'peg'. If
Zend is to settle on everything being longs or everything being ints,
then people have to be stopped from reintroducing the 'wrong' type and
people are going to have problems when the 'other' storage is the only
one that appears to fit the job.

Given the gradual divergence of Zend  PHP from 64-bit cleanliness, I
had thought these things to be fairly urgent and fundamental. In any
case, the number of users and lines of code influenced by these issues
has become increasingly visible in public over the last four months.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #22291 [Opn-Bgs]: CGI do not function !

[James Devenish]

In message [EMAIL PROTECTED]
on Wed, Feb 19, 2003 at 11:34:21AM +0100, Magnus M wrote:
 On Wed, 19 Feb 2003 11:27:51 +0100
 Vincent Robert [EMAIL PROTECTED] wrote:
 
  It's a bug 
  
  I'm not the only one, look #22292
 
 And then it's a duplicate, and therefor marked bogus.
 If you have any additional information that can be useful, not already known,
 please add it to that bug.

So...this thread is discussing #22291 (which Vincent Robert) submitted.
He then comments that bug #22292 (posted half an hour after his)
indicates the same problem but is told by two people that his (earlier)
bug is bogus because it is a duplicate of a bug (presumably the one he
mentioned: the one that was submitted in the future)? BTW he has already
commented in bug #22292 as far as I can see. Just an observation.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)

[James Devenish]

Hi, just some followup, including some general build problems and some
information about failed tests at the bottom. I have included a set of
patches against 4.3.0pre2 and against CVS HEAD for anyone who's
interested in seeking some form of success with PHP 4.3 on a 64-bit
platform.

Someone will need to tell me what mailing lists to send to, etc (I am
on php-dev and php-qa to read followups). I'm not sure how to get `make
test` results to you as the script asks 'would you like to send the
report to PHP's QA team' but I say 'n' because I can't send or receive
mail on the machine that I am testing on. I had a few notes about them,
too. note: I have just real run-tests.php and see a that it submits
over the web. Will use to this sometime

The `make test` target doesn't work on my test machine (either in the
4.3.0pre2 or when using buildconf) because my $(CC) contains a space
character. So as the target is:

test: $(SAPI_CLI_PATH)
TEST_PHP_DETAILED
TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \
 TEST_PHP_SRCDIR=$(top_srcdir) \
 CC=$(CC) \
$(top_builddir)/$(SAPI_CLI_PATH) $(top_srcdir)/run-tests.php 
$(TESTS)

I change thae second-last line to :
 CC=$(CC) \
to make it work for me. I don't know how that should be handled in general but
I thought I should point it out.

Okay, `make test` still not work. Many segfaults in mbstring.

Also, there seems to be something wrong because there are multiple definitions
of url_adapt_ext, yet only one is used. Also a patch for network.c.

The attached patches are against 4.3.0pre2, which is what I ran `make test`
with, though I am actually using CVS HEAD with my test web server.
(From a few days ago.)

Note: I only just realised that if I run `make test` and it print no
output other than 'Bus error' for a while, it *is* actually testing
correctly. I didn't realise that `make test` only prints test results at
the very end and I had been killing it in the middle of the test because
it didn't seem to be working

So, the patch includes: sundry correction of (int size)=(pointer size)
assumptions, introduction of OnUpdateLong, some zend_parse_parameters fixes. 
Does not address all instances of sizeof( blah_t ) != sizeof( operand ).

=
FAILED TEST SUMMARY
-
mb_strtoupper() / mb_strtolower() [ext/mbstring/tests/casefold.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
mb_convert_encoding() [ext/mbstring/tests/mb_convert_encoding.phpt]
mb_ereg() [ext/mbstring/tests/mb_ereg.phpt]
mb_ereg_search() stuff [ext/mbstring/tests/mb_ereg_search_xxx.phpt]
mb_strlen() [ext/mbstring/tests/mb_strlen.phpt]

**mbstring: extensive issues with mixed int/pointer.

Test array_merge and array_walk [ext/standard/tests/array/001.phpt]
Test arsort, asort, krsort, ksort, rsort, and sort [ext/standard/tests/array/002.phpt]
Test usort, uksort and uasort [ext/standard/tests/array/003.phpt]

**array tests: error in the tests: ext/standard/tests/array/data.inc
  contains monkey whereas the test expected results do not. Also, one
  test uses pow(2,64) and expects the result to overflow in a 32-bit way.
  These problems have been partially fixed in CVS already.

var_dump float test [ext/standard/tests/general_functions/008.phpt]
overflow check for _php_math_basetozval [ext/standard/tests/math/hexdec.phpt]

**var_dump and hexdec: the expected overflows do not occur with 64-bit
  operands :)

Simple math tests [ext/standard/tests/math/abs.phpt]
Simple math tests [ext/standard/tests/math/round.phpt]

**maths tests: issues with LONG_MIN and LONG_MAX

Various pow() tests [ext/standard/tests/math/pow.phpt]

**no comment from me

crc32() function [ext/standard/tests/strings/crc32.phpt]

**crc32: uses Zend's RETVAL_LONG but test expects 32-bit overflow.

strtotime() function [ext/standard/tests/time/002.phpt]

**no comment from me

Methods via variable name, bug #20120 [tests/classes/bug20120.phpt]

**My bison is bison-1.50, addressed by the bug fix (closed). This
  problem was also visible as an error message during PEAR
  installation.

=

Given the bison problem, my previous comments about Zend might be
doubtful. working Mmm, new bison fixed the last failed test. Other
tests unchanged wrt 4.3.0pre2. Latest CVS version currently seems to
have various other problems and I'll assume that's just code flux and I
will try again later.

--end--


Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.23
diff -u -r1.23 zend_ini.c
--- Zend/zend_ini.c 23 Sep 2002 12:00:39 -  1.23
+++ Zend/zend_ini.c 11 Nov 2002 03:02:32 -
 -430,6 +430,23 
 
 ZEND_API ZEND_INI_MH(OnUpdateInt)
 {
+   int *p;
+#ifndef ZTS
+   char *base = (char *) 

[PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)

[James Devenish]

Hi,

Referring to bug #20268 (Bus Error on startup), I have added some
comments about show-stopping problems with PHP 4.3 with regards to its
lack of 64-bit cleanliness.  The main problems seem to be Zend's
OnUpdateInt (which seems misnamed although it uses zend_atoi, it assigns
to a long) and PHP modules' use of zend_parse_parameters (which again
acts on longs, not ints, though that has slipped by the authors of some
modules).  (Please forgive some of the less coherent sentences in my
comments on the bug.) I have provided patches that demonstrate how I
managed to get PHP working (in particular with SPARCv9 Solaris 8 and
Apache 2.0).

Regards,
A random but concerned 64-bit user.



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php