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
>

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

Reply via email to