Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
Why not just convert to using a long? Is there really a need to have 2 numeric types in the ini system? -Jason On Mon, 2002-11-11 at 00:20, Andi Gutmans wrote: Hi, How about changing the INI_ENTRY macros in debug mode to check if we're using UpdateInt/UpdateLong and if so check if sizeof(param) == sizeof(int/long)? This could help a lot. Andi At 01:12 PM 11/11/2002 +0800, James Devenish wrote: 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
Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
Well I assume lots of extension maintainers are using int's for all sorts of things. I'm not sure it's a good idea to try and catch every last place. In any case, even if we convert everything then my suggestion still stands because it'd help us catch places which aren't defined correctly. Andi At 10:42 AM 11/11/2002 -0600, Jason T. Greene wrote: Why not just convert to using a long? Is there really a need to have 2 numeric types in the ini system? -Jason On Mon, 2002-11-11 at 00:20, Andi Gutmans wrote: Hi, How about changing the INI_ENTRY macros in debug mode to check if we're using UpdateInt/UpdateLong and if so check if sizeof(param) == sizeof(int/long)? This could help a lot. Andi At 01:12 PM 11/11/2002 +0800, James Devenish wrote: 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
Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
On Monday, November 11, 2002, at 02:39 PM, Andi Gutmans wrote: Well I assume lots of extension maintainers are using int's for all sorts of things. I'm not sure it's a good idea to try and catch every last place. In any case, even if we convert everything then my suggestion still stands because it'd help us catch places which aren't defined correctly. Maybe I've missed the point, or I'm too tired to connect neurons today. But what is the point of trying to correct for places which aren't defined correctly? This seems like a rather odd/bad way of looking at this. If you've defined incorrectly, it just shouldn't work. I'd rather lean towards Jason's suggestion --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- 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)
OK, though I wasn't arguing against your suggestion; I should have responded to the previous email in the thread. I was just pointing out that supporting these two may be overkill, but if its being used as a stop-gap, and since it doesn't really hurt that much, I suppose it really doesn't matter. -Jason On Mon, 2002-11-11 at 10:42, Jason T. Greene wrote: Why not just convert to using a long? Is there really a need to have 2 numeric types in the ini system? -Jason On Mon, 2002-11-11 at 00:20, Andi Gutmans wrote: Hi, How about changing the INI_ENTRY macros in debug mode to check if we're using UpdateInt/UpdateLong and if so check if sizeof(param) == sizeof(int/long)? This could help a lot. Andi At 01:12 PM 11/11/2002 +0800, James Devenish wrote: 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
Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
At 04:31 PM 11/11/2002 -0500, Dan Kalowsky wrote: On Monday, November 11, 2002, at 02:39 PM, Andi Gutmans wrote: Well I assume lots of extension maintainers are using int's for all sorts of things. I'm not sure it's a good idea to try and catch every last place. In any case, even if we convert everything then my suggestion still stands because it'd help us catch places which aren't defined correctly. Maybe I've missed the point, or I'm too tired to connect neurons today. But what is the point of trying to correct for places which aren't defined correctly? This seems like a rather odd/bad way of looking at this. If you've defined incorrectly, it just shouldn't work. I'd rather lean towards Jason's suggestion Hmm, the thing is that it will work even if he have one version. It'll compile and even work on some machines. I'm saying that in debug mode we change the macro to make sure that sizeof(param) == sizeof(type). Andi -- 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)
I started to work on fixing this problem, but have not had time to finish my work. I will try to get some time available to work on this sometime soon. Thanks, -Jason On Sat, 2002-11-09 at 22:25, James Devenish wrote: 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 -- Jason Greene [EMAIL PROTECTED] [EMAIL PROTECTED] The honeymoon is over when he phones to say he'll be late for supper and she's already left a note that it's in the refrigerator. -- Bill Lawrence -- 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)
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 *)
Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
Hi, How about changing the INI_ENTRY macros in debug mode to check if we're using UpdateInt/UpdateLong and if so check if sizeof(param) == sizeof(int/long)? This could help a lot. Andi At 01:12 PM 11/11/2002 +0800, James Devenish wrote: 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-- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To
[PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)
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
