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
