Re: Re: [PATCH] double to long conversion change

Hi again, OK, I will go ahead and commit the patch + test updates in about 24 hours... - Matt ----- Original Message ----- From: "Matt Wilmas" Sent: Friday, May 29, 2009

Hi all, ----- Original Message ----- From: "Matt Wilmas" Sent: Friday, April 10, 2009

Hi Dmitry, I finally updated the patches: http://realplain.com/php/dval_to_lval.diff http://realplain.com/php/dval_to_lval_5_3.diff

The patches were updated again, against current CVS (no changes by me). After some off- and on-list discussion weeks ago, it sounds like (from Stas) these changes are acceptable to restore float->int conversion to the long-standing behavior that exists through PHP 5.2 (for most users/platforms), as long as the necessary tests were updated, which I've done for ones I checked. At least I haven't heard any negative feedback since my final proposal? :-) Patches for test updates: http://realplain.com/php/dval_to_lval_tests.diff http://realplain.com/php/dval_to_lval_tests_5_3.diff ext/standard/tests/url/parse_url_variation_002.phpt was split into 32- and 64-bit versions again (like 5.2). If other failing tests are found, let me know. I guess I could go ahead and commit the changes next week if there aren't objections... Was wondering about two minor parts, explained previously, OK to keep?: 1) Configure check for whether just a simple (long) cast gives the desired result, to save runtime range checking. (Not sure how many platforms would pass this, other than Windows' VC6.) 2) The 'L' conversion specifier for zend_parse_parameters() (I've updated README.PARAMETER_PARSING_API). Like I said, some functions could be updated to use this (with "limit" or "length" type params) to prevent overflow-related weirdness if huge numbers are passed. It should be noted that such unexpected behavior has existed through 5.2, however, though the changes in 5.3 started to prevent it in a lot of cases (very inconsistent though; Bug #47854, etc.). Thanks, Matt