Re: Re: Bug #46701

Hi Zoe, all, ----- Original Message ----- From: "zoe" Sent: Wednesday, February 18, 2009 > Moriyoshi Koizumi wrote: > > Please don't even think of backporting. This will definitely break a > > lot of things, and this kind of thing must not be done in a minor > > release. > > > > > --snip-- > > >>>> 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. (I'm glad this change was reverted for 5.2...) Anyway, like I said in my "5.3 todos" reply, I'll send a possible DVAL_TO_LVAL, etc. solution (consistent/reliable overflow across platforms) for consideration as soon as I can... There are other inconsistencies and behavior changes with the existing code, and it definitely doesn't behave in a platform-independent way! With the 4 versions of DVAL_...: old, 32 bit, 64 bit, 64 bit Windows (not sure why it's there; its longs are still 32 bit?), things I can think of: - 64-bit Windows has no range limiting for casting, so it's free to overflow like the old way...? Other 64 bit limits the range to LONG_MAX/MIN. 32 bit still casts between LONG_MAX and MAX_UNSIGNED_INT (ULONG_MAX-ish?), and, presumably, it's supposed to overflow between those 2, but casting of the out-of-range unsigned long is also "implementation-defined," so still cannot be guaranteed. - Conversion of INF/-INF: the old version and 64 bit Windows now will convert them to 0. 32 bit and other 64 bit will convert them to LONG_MAX/LONG_MIN. - With zend_parse_parameters(), a numeric string that results in a double is still converted using a simple (long) cast only. (In my proposed changes, I was going to add a new conversion specifier (simple few lines), like capital 'L', for functions that want/need to limit the long without overflow, like lengths for some string functions that I *thought* was trying to be fixed orginally.) > Zoe - Matt