To summarize what were the problems: 1. casting a float value that is unrepresentable in a target type is undefined according to C spec. 2. any constant values that are unrepresentable in the standard integer type are automagically represented as double values in PHP. i.e. 0xc0000000 will result in a double value in the 32bit architecture. 3. PHP's cast behavior used to rely on the C cast, which was addressed in #42868 and fixed for 5.3.x and later. 4. PHP's associative array allows strings and integers for its keys. 5. when a double value is fed to an array as the key, it is converted to integer using the standard C cast. 6. bug #46701 addresses the problem that the result of 6. varies by the architecture. 7. the patch for bug #46701 uses DVAL_TO_LVAL to get the consistent cast behavior. 8. therefore, it's natural to consider bug #46701 is based on the behavior that is achieved by the patch for bug #42868. 9. the patch for bug #42868 may affect existing applications that rely on the old behavior. (http://marc.info/?l=php-internals&m=120799720922202&w=2) 10. the change like 9. is not tolerable in a minor release. 11. if bug #42868 is not going to be merged, then bug #46701 should be reverted from the 5.2 branch.
Moriyoshi On Wed, Feb 18, 2009 at 8:28 PM, zoe <zoe.slatt...@googlemail.com> wrote: > Moriyoshi Koizumi wrote: >>>>> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was >>>>> changed by the fix for bug #42868, right? >>>>> If so, this patch shouldn't be MFH'ed as the #42868 patch was not >>>>> merged although I didn't remember any discussion on this. >>>>> >>>>> See also: http://marc.info/?l=php-internals&m=120799720922202&w=2 >>>>> >>>>> > > Hey all > > I'm sorry - I should have replied to this before since I was responsible for > raising #42868. I didn't do a good job at explaining what the issue was in > that bug, mainly because I didn't know what it was when I started. The > central problem is that PHP's behaviour on casting double to int defaults to > whatever the underlying C environment does. On Windows and Linux (all of the > versions that I looked at) this turns out to be a simple truncation of the > last 32 bits. Unfortunately the C behaviour is 'undefined' (Kernigan and > Ritchie, page 197, A6.3). The issue that I found in #42868 was that on the > Mac the casting behaviour is completely different so many of the PHP tests > failed. I believe that PHP should behave in a platform independent way - > that is what the fix to #42868 achieves. It is also fair to say that any > applications that depend on the overflow behaviour in PHP 5.2 cannot be > guaranteed to run on any platform. > > Zoe >>>>> >>>>> Regards, >>>>> Moriyoshi >>>>> >>>>> >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>>> >>> >>> Ilia Alshanetsky >>> >>> >>> >>> >>> >>> >> >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
