Re: 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 (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 unsubscribe, visit: http://www.php.net/unsub.php