On 02/05/2013 12:33 AM, Remi Collet wrote: > Le 05/02/2013 08:54, Stas Malyshev a écrit : >> Hi! >> >>> - if (d > LONG_MAX) { >>> + if (d >= LONG_MAX) { >>> return (long)(unsigned long) d; >>> } >>> return (long) d; >> >> Could you please explain this one? I thought LONG_MAX is a largest >> permissible long value, why when d==LONG_MAX we need to convert? > > LONG_MAX is the largest "unsigned" value. > We have different int/float conversion result on some arch (detected, at > least on ppc64). > > long l = 0x7fffffffffffffff; > double d; > d = l; > d++; > printf("max+1=%lf, %ld, 0x%lx\n", d, (long)d, (long)d); > printf("max+1=%lf, %ld, 0x%lx\n", d, (long)(unsigned long)d, > (long)(unsigned long)d); > > > On x86_64 > max+1=9223372036854786048.000000, -9223372036854775808, 0x8000000000000000 > max+1=9223372036854786048.000000, -9223372036854765568, 0x8000000000002800 > > ON ppc64 > > max+1=9223372036854775808.000000, 9223372036854775807, 0x7fffffffffffffff > max+1=9223372036854775808.000000, -9223372036854775808, 0x8000000000000000 > > So we are in a really border case... > >> Also, why this patch - which seems to be a BC break since it exhibits >> different behavior on 64-bit systems - needs to be in 5.4? > > This patch doesn't change behavior on x86 arch. > It fixes 9 failed test on ppc64.
I guess the confusion here is that without an #ifdef PPC around this, how is this not triggering the conversion earlier on x86? Also, I tried your test program on my x86_64 Linux box and I don't get the same result: I get: max+1=9223372036854775808.000000, -9223372036854775808, 0x8000000000000000 max+1=9223372036854775808.000000, -9223372036854775808, 0x8000000000000000 gcc-4.7, glibc-2.15 -Rasmus -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php