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