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

Reply via email to